Re: Urp(!) - indeterminant connection SO_NONBLOCK state?

[Brian Pane <br...@apache.org>]

On Sep 30, 2005, at 11:19 AM, William A. Rowe, Jr. wrote:

> Linux, Win32 and Netware begin their new socket's life in a blocking
> state, while Solaris and AIX begin their life in a non-blocking state.
[...]
> Do we want to;
>
>  * Fix mod_echo with this gross little hack?  (and leave it to each
>    protocol module author?)
>
>  * Modify mod_ssl so that APR_BLOCK_READ actually toggles the socket
>    to blocking mode (or keeps reinvoking the core until it gets the
>    bytes that SSL demands)?
>
>  * Modify the core so that APR_BLOCK_READ actually toggles the socket
>    blocking mode?
>
>  * Modify the MPM such that the newly accept()ed socket is toggled
>    into blocking mode?
>
>  * Modify APR such that a newly created socket's state is of some
>    known value?  (Right now, it pretends that it knows if the platform
>    has predetermined that the accept()ed socket's state is inherited
>    from the listening socket - and Linux's state proves this  
> assumption
>    was invalid.)
>
> Thoughts/comments?

I think the 3rd option--modify the core so that APR_BLOCK_READ actually
toggles the socket blocking mode--might be the best way to go.  This  
would
provide predictable semantics for modules that know they want to do
blocking reads, while still allowing the MPM to put newly accepted  
sockets
in nonblocking mode by default if the MPM has some good reason to do so.

Brian