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

Reply via email to