Re: New documentation: NSPR functions required for using NSS
On Mon, Sep 8, 2008 at 5:44 PM, Kyle Hamilton [EMAIL PROTECTED] wrote: What is the semantic if someone opens the TCP socket in O_NONBLOCK in the first place? The PRFileDesc* returned by PR_ImportTCPSocket is in blocking mode. If the caller intends to use the PRFileDesc* in non-blocking mode, he needs to call PR_SetSocketOption to set the PRFileDesc* in non-blocking mode. The reason that NSPR puts the native file descriptor in non-blocking mode for a PRFileDesc* in blocking mode is to implement the I/O timeout and interrupt of PR_Recv and PR_Send. PR_Recv blocks in poll() instead of recv() because poll() takes a timeout parameter. So, PR_ImportTCPSocket doesn't check if the native file descriptor is already in non-blocking mode. It always sets the O_NONBLOCK flag on the native file descriptor, and the returned PRFileDesc* starts in blocking mode. (Also, I found http://www.faqs.org/faqs/unix-faq/socket/ section 2.9. It doesn't exactly help all that much in explaining what goes on, but does PR_ImportTCPSocket's implementation (and thus the entirety of NSPR) add something to handle SIGIO? Or is it more of a select() with a timeout of 0?) NSPR doesn't use SIGIO. NSPR uses poll() (equivalent to select()) because it has a timeout parameter as I explained above. Note that the first paragraph of Section 2.9 of Unix-socket-faq that you cited is misleading. Non-blocking I/O is usually used with select()/poll(). Non-blocking I/O doesn't mean you have to poll the sockets individually. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New documentation: NSPR functions required for using NSS
On Tue, Sep 9, 2008 at 8:37 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote: Rob Crittenden wrote, On 2008-09-09 20:18: Does this mean than an explicit PR_Init() is not required? Whenever you call a public PR_ function, if NSPR is not already initialized, it will get initialized by that first call. (*) However, NSPR initialization should only be done on one thread. It's bad if multiple threads call NSPR Functions that all try to initialize NSPR simultaneously. PR_Init exists to provide a way to initialize NSPR at a point in the program when the programmer is sure that no other thread can possibly be using NSPR. You're right. So PR_Init still has some value. The best solution to this problem is for libnspr4.so to call NSPR initialization at shared library initialization time (the so-called _init routine). We should do this on all POSIX systems. We may not be able to do this on Windows because Windows imposes severe constraints on what functions DllMain may call. Note: (*) I'm not sure this is correct for 100% of the public NSPR PR_ functions, but I believe it is true for the vast majority. It may be that some functions, such as those that operate on open PRFileDescriptors, may not initialize NSPR, because they reasonably assume that the functions that returned those newly opened PRFileDescriptors would have initialized NSPR. This is speculation. Perhaps Wan-Teh will make an authoritative statement about this. Yes. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New documentation: NSPR functions required for using NSS
Rob Crittenden wrote, On 2008-09-09 20:18: Does this mean than an explicit PR_Init() is not required? Whenever you call a public PR_ function, if NSPR is not already initialized, it will get initialized by that first call. (*) However, NSPR initialization should only be done on one thread. It's bad if multiple threads call NSPR Functions that all try to initialize NSPR simultaneously. PR_Init exists to provide a way to initialize NSPR at a point in the program when the programmer is sure that no other thread can possibly be using NSPR. Note: (*) I'm not sure this is correct for 100% of the public NSPR PR_ functions, but I believe it is true for the vast majority. It may be that some functions, such as those that operate on open PRFileDescriptors, may not initialize NSPR, because they reasonably assume that the functions that returned those newly opened PRFileDescriptors would have initialized NSPR. This is speculation. Perhaps Wan-Teh will make an authoritative statement about this. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New documentation: NSPR functions required for using NSS
I'm pretty sure there are some things that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK mode, but I can't think of any off the top of my head. Is there a reference somewhere that lists the kinds of things that a programmer needs to avoid? If there is, could the documentation page link to it, or import it? Thank you very much for documenting this! -Kyle H On Mon, Sep 8, 2008 at 4:35 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote: As part of the work to include NSS in LSB 4.0, I created a list of NSPR functions required for using the NSS SSL functions at http://developer.mozilla.org/En/NSS_reference/NSPR_functions I generated this list by inspecting the source code of libcurl, nss_compat_ossl, mod_nss, and the NSS test programs selfserv, tstclnt, strsclnt, vfyserv, and vfychain. Note, in particular, that I documented the PR_ImportTCPSocket function, giving an official blessing to use this function when you know what you're doing. Please let me know if I have explained the caveats adequately without discouraging people from using this convenient function under the right circumstances. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New documentation: NSPR functions required for using NSS
On Mon, Sep 8, 2008 at 5:14 PM, Kyle Hamilton [EMAIL PROTECTED] wrote: I'm pretty sure there are some things that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK mode, but I can't think of any off the top of my head. Is there a reference somewhere that lists the kinds of things that a programmer needs to avoid? If there is, could the documentation page link to it, or import it? I haven't written such a reference. I don't know anything that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK off the top of my head either. Rather than listing the kinds of things that a programmer needs to avoid, perhaps we can require the caller to return the native socket to the pristine mode it was created in by the socket() system call? This could be overly restrictive because some modes, such as the close-on-exec flag, won't interfere with the O_NONBLOCK mode. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New documentation: NSPR functions required for using NSS
On Mon, Sep 8, 2008 at 5:37 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote: On Mon, Sep 8, 2008 at 5:14 PM, Kyle Hamilton [EMAIL PROTECTED] wrote: I'm pretty sure there are some things that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK mode, but I can't think of any off the top of my head. Is there a reference somewhere that lists the kinds of things that a programmer needs to avoid? If there is, could the documentation page link to it, or import it? I haven't written such a reference. I don't know anything that can be done to put a TCP socket into a state that's inappropriate for O_NONBLOCK off the top of my head either. Rather than listing the kinds of things that a programmer needs to avoid, perhaps we can require the caller to return the native socket to the pristine mode it was created in by the socket() system call? This could be overly restrictive because some modes, such as the close-on-exec flag, won't interfere with the O_NONBLOCK mode. Wan-Teh What is the semantic if someone opens the TCP socket in O_NONBLOCK in the first place? (Also, I found http://www.faqs.org/faqs/unix-faq/socket/ section 2.9. It doesn't exactly help all that much in explaining what goes on, but does PR_ImportTCPSocket's implementation (and thus the entirety of NSPR) add something to handle SIGIO? Or is it more of a select() with a timeout of 0?) -Kyle H ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
