httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: Problem with apr_setsocketopt() and apr_getsockopt()....
Date Fri, 07 Jun 2002 21:48:27 GMT
    Actually the Unix socket.c code is doing exactly what you suggested.
 But it only does it for TCP_NODELAY and SO_NONBLOCK.  Are these the
only two options that can be inherited and we need to worry about?  Part
of the problem for NetWare is that this code was never ported to the
Win32/NetWare socket.c code when the other changes were made.  I just
finished making these changes to the Win32/NetWare socket code and
checked it in.  This seemed to solve the non-responsive problem that we
were seeing.  The two #defines that are necessary in order to turn on
this functionality is APR_TCP_NODELAY_INHERITED and
APR_O_NONBLOCK_INHERITED.  I defined them for NetWare but I don't know
if they are needed in Windows or not.  If so, then whoever is
responsible for sockets on Windows might want to define these compile
flags in include/apr.hw.

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., a leading provider of Net business solutions
http://www.novell.com 

>>> brian.pane@cnet.com Friday, June 07, 2002 3:21:43 PM >>>
Brad Nicholes wrote:

>  With the change that was made to these functions where the state of
>the socket option is determined by our own mask rather than querying
the
>socket, makes an assuption about the initial state of the socket. 
Since
>the mask is initialized to 0 when the socket is created, the
assumption
>is made that the initial state is off.  Is this always true for every
>socket option?  This kind of assuption seems a little dangerous. 
With
>this change, NetWare is currently failing to respond to about half of
>the requests made to the web server.  From what I can tell so far,
the
>failure is because a socket is determined to already be in a blocking
>state when the call is make to set it to blocking.  When in fact, the
>socket is really in a nonblocking state and the mask is not insync
with
>the real state only because it was never initialized.  Don't we need
to
>first query the socket to determine its initial state and then base
the
>mask off of the results of the query?  Or bite the bullet and make
the
>requested call rather than trying to short circuit the process?
>

I'm generally opposed to doing an initial query; even though that's
the safe solution, it's too much of a performance impact on some
systems (Solaris, for example, where getting or setting the
nonblocking
state is a bit slow).

However, I wonder if we can solve the problem by extending the checks
that we do in the apr configure script to figure out which socket
options are inherited upon accept.  What I'm thinking of is:
   * During configuration, figure out what the default value for each
     flag is for a newly created socket, and which of those flags are
     inherited during an accept.
   * In the APR socket code, initialize the apr_socket_t flags
according
     to the information determined during configuration, rather than
     blindly setting the flags to zero.

It's been a while since I looked at that code, so this idea might or
might
not make sense.  What do you think?

--Brian



Mime
View raw message