On Sat, 21 Mar 2009, John D wrote:
I wonder how thread safe NSS' integration with libcurl actually is. No
offense Daniel but after switching to gnutils with their macros all problems
related to this matter are resolved. So be it.
I'm absolutely sure on how we use NSS in libcurl, and the nss.
2009/3/20 John D :
>
> I have attempted this to the result of
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1810576496 (LWP 3177)]
> 0xb79e6547 in NL_VersionCheck () from /usr/lib/libssl3.so.1d
> (gdb) where
> #0 0xb79e6547 in NL_VersionCheck () from /usr
I wonder how thread safe NSS' integration with libcurl actually is.
No offense Daniel but after switching to gnutils with their macros
all problems related to this matter are resolved. So be it.
Kind thanks,
JD
On 3/21/09, John D wrote:
>
>
>
> On 3/21/09, Wan-Teh Chang wrote:
>>
>> It is an
On 3/21/09, Wan-Teh Chang wrote:
>
> It is an application's responsibility to call sigaction to ignore
> SIGPIPE. You can do that with the following code:
>
>#include
>
>struct sigaction sigact;
>sigact.sa_handler = SIG_IGN;
>sigemptyset(&sigact.sa_mask);
>sigact.sa_flags = 0
It is an application's responsibility to call sigaction to ignore
SIGPIPE. You can do that with the following code:
#include
struct sigaction sigact;
sigact.sa_handler = SIG_IGN;
sigemptyset(&sigact.sa_mask);
sigact.sa_flags = 0;
sigaction(SIGPIPE, &sigact, NULL);
But y
On 3/21/09, John D wrote:
>
>
>
> On 3/21/09, Daniel Stenberg wrote:
>>
>> On Fri, 20 Mar 2009, Julien R Pierre - Sun Microsystems wrote:
>>
>> NSS team: Is PR_Init() thread-safe?
>>>
>>> No, it is not thread-safe by definition, and must be called and completed
>>> before any other call to
On 3/21/09, Daniel Stenberg wrote:
>
> On Fri, 20 Mar 2009, Julien R Pierre - Sun Microsystems wrote:
>
> NSS team: Is PR_Init() thread-safe?
>>>
>>
>> No, it is not thread-safe by definition, and must be called and completed
>> before any other call to NSPR functions are made in any other thread
On Fri, 20 Mar 2009, Julien R Pierre - Sun Microsystems wrote:
NSS team: Is PR_Init() thread-safe?
No, it is not thread-safe by definition, and must be called and completed
before any other call to NSPR functions are made in any other thread.
Typically, PR_Init is called in the primordial th
Daniel,
Daniel Stenberg wrote:
NSS team: Is PR_Init() thread-safe?
No, it is not thread-safe by definition, and must be called and
completed before any other call to NSPR functions are made in any other
thread. Typically, PR_Init is called in the primordial thread.
--
dev-tech-crypto mail
On Fri, 20 Mar 2009, Wan-Teh Chang wrote:
I didn't mean that SIGPIPE is ignored only during NSPR initialization. I
meant that NSPR's initialization function calls sigaction to ignore SIGPIPE.
Oh, well that might just've been me being thick sorry. Still I read you now
loud and clear, thanks!
On Fri, 20 Mar 2009, John D wrote:
Each thread created, will call a function that runs a curl easy setopt
operation.
John: Do you call the curl_global_init() before you start any threads and use
libcurl? Can you get some further symbols in the stack trace to help me/us
with seeing who calls
On Fri, Mar 20, 2009 at 3:42 PM, Daniel Stenberg wrote:
> On Fri, 20 Mar 2009, Wan-Teh Chang wrote:
>
>> But I agree that SIGPIPE is an exception. This is why NSPR (a depenency
>> of NSS) calls sigaction() to ignore SIGPIPE during initialization. Note
>> that this is done for self protection, ra
On 3/20/09, Daniel Stenberg wrote:
>
> On Fri, 20 Mar 2009, Wan-Teh Chang wrote:
>
> But I agree that SIGPIPE is an exception. This is why NSPR (a depenency of
>> NSS) calls sigaction() to ignore SIGPIPE during initialization. Note that
>> this is done for self protection, rather than as a docum
On Fri, 20 Mar 2009, Wan-Teh Chang wrote:
But I agree that SIGPIPE is an exception. This is why NSPR (a depenency of
NSS) calls sigaction() to ignore SIGPIPE during initialization. Note that
this is done for self protection, rather than as a documented service to the
NSPR client.
But doesn
On 3/20/09, Wan-Teh Chang wrote:
>
> Nelson's point is that signal handlers are process-wide
> properties, and it is inappropriate for a library to change
> a process-wide property.
>
> But I agree that SIGPIPE is an exception. This is why
> NSPR (a depenency of NSS) calls sigaction() to ignore
>
Nelson's point is that signal handlers are process-wide
properties, and it is inappropriate for a library to change
a process-wide property.
But I agree that SIGPIPE is an exception. This is why
NSPR (a depenency of NSS) calls sigaction() to ignore
SIGPIPE during initialization. Note that this i
On 3/20/09, Daniel Stenberg wrote:
>
> On Fri, 20 Mar 2009, Nelson B Bolyard wrote:
>
> It would be inappropriate for NSS to defeat sigpipe's signal handler. The
>> handling of that signal is the responsibility of the application, or code at
>> a higher level than NSS. Perhaps it would be appropr
On Fri, 20 Mar 2009, Nelson B Bolyard wrote:
It would be inappropriate for NSS to defeat sigpipe's signal handler. The
handling of that signal is the responsibility of the application, or code at
a higher level than NSS. Perhaps it would be appropriate for libcurl to do
that.
SIGPIPE is a s
On 3/20/09, Nelson B Bolyard wrote:
>
> John D wrote, On 2009-03-20 11:30:
> > This is an issue involving sigfaults caused by broken pipes when using
> > fast moving multithreaded libcurl NSS. The issue is that I am unaware of
> > how to properly implement the correct signal handler or even to ign
John D wrote, On 2009-03-20 11:30:
> This is an issue involving sigfaults caused by broken pipes when using
> fast moving multithreaded libcurl NSS. The issue is that I am unaware of
> how to properly implement the correct signal handler or even to ignore
> the sigpipe and carry forward. My own co
Good day
This is an issue involving sigfaults caused by broken pipes when using fast
moving multithreaded libcurl NSS.
The issue is that I am unaware of how to properly implement the correct
signal handler or even to
ignore the sigpipe and carry forward. My own code will correct for a sigpipe
prov
21 matches
Mail list logo
