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 cono...@gmail.com wrote:
On 3/21/09, Wan-Teh Chang
2009/3/20 John D cono...@gmail.com:
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 ()
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
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
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 code
On 3/20/09, Nelson B Bolyard nel...@bolyard.me 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
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
On 3/20/09, Daniel Stenberg dan...@haxx.se 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
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
On 3/20/09, Wan-Teh Chang w...@google.com 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
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
On 3/20/09, Daniel Stenberg dan...@haxx.se 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
On Fri, Mar 20, 2009 at 3:42 PM, Daniel Stenberg dan...@haxx.se 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
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, 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, 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
On 3/21/09, Daniel Stenberg dan...@haxx.se 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
It is an application's responsibility to call sigaction to ignore
SIGPIPE. You can do that with the following code:
#include signal.h
struct sigaction sigact;
sigact.sa_handler = SIG_IGN;
sigemptyset(sigact.sa_mask);
sigact.sa_flags = 0;
sigaction(SIGPIPE, sigact, NULL);
On 3/21/09, Wan-Teh Chang w...@google.com wrote:
It is an application's responsibility to call sigaction to ignore
SIGPIPE. You can do that with the following code:
#include signal.h
struct sigaction sigact;
sigact.sa_handler = SIG_IGN;
sigemptyset(sigact.sa_mask);
19 matches
Mail list logo
