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 ignore > SIGPIPE during initialization. Note that this is done for > self protection, rather than as a documented service > to the NSPR client. > > So the issue is why you receive SIGPIPE while calling > NSSSSL_VersionCheck (). This implies that NSPR > hasn't been initialized at that point. > > NSPR is implicitly initialized by the first NSPR function > call that requires NSPR to be initialized. > NSSSSL_VersionCheck is a trivial function and doesn't > require NSPR to be initialized, so NSSSSL_VersionCheck > doesn't cause NSPR to be initialized. If > NSSSSL_VersionCheck is the very first NSPR/NSS call > made by the application, NSPR won't be initialized at > that point. If your app want to depend on NSPR's > undocumented sigaction call for SIGPIPE, you can call > PR_Init before calling NSSSSL_VersionCheck: > https://developer.mozilla.org/en/PR_Init > > Wan-Teh > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto >
Well thank you. I am now eager to hear how this information ties to libcurl's initialization with nss. By all means Daniel this is clearly of benefit. John
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
