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 w
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
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 definit
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
ater?
>
> So the issue is why you receive SIGPIPE while calling NL_VersionCheck
>> (). This implies that NSPR hasn't been initialized at that point.
>>
>
> John D, what is calling NL_VersionCheck() before th PR_Init() call?
> libcurl does nothing SSL at all before callin
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
>
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 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 s
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
9 matches
Mail list logo
