apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: proposed change to reduce nonblocking socket performance overhead
Date Mon, 10 Dec 2001 04:30:31 GMT
On Sunday 09 December 2001 06:55 pm, Brian Pane wrote:
> sononblock()--the function in apr/networkio/unix/sockopt.c
> that puts sockets in blocking or nonblocking mode--is
> responsible for a surprisingly large amount of CPU time
> on Solaris.  I used to think that this was inevitable, but
> upon closer inspection there might be a way to fix it...
> but I'd like to get some feedback on whether the fix would
> actually be safe.
> The logic for setting the nonblocking state looks like
> this:
>   - fcntl(sd, F_GETFL, ...) to get the current flags on
>     the socket descriptor
>   - OR the flags with O_NONBLOCK or O_NDELAY or O_FNDELAY,
>     depending on the OS.
>   - fcntl(sd, F_SETFL, flags) to set the new flags.
> According to the profiler data, the F_GETFL fcntl operation
> is more expensive than the F_SETFL one.
> Thus the change that I'm thinking of is:
>   - on the first sononblock() call on a newly accepted
>     socket, skip the F_GETFL operation and assume that
>     the current flags are zero.
> By my reading of the man pages, this ought to be safe
> because the fcntl-set options on the listener socket
> aren't inherited by the new socket that's created upon
> accept.  But is there any platform (among the UNIXes
> supported by APR) where it's *not* safe to make this
> assumption?

Yeah, unfortunately some platforms do inherit these flags.

Can we improve the performance by only doing the F_GETFL
once though?  If we do it once, and cache the results in the
apr_sockopt, we should be safe.  Then the only problem is that we
have to keep them up to date whenever we use F_SETFL, but I think
we can handle that.

Of course, it means that once a socket is under APR control, you
can't set options outside of APR and be safe.


Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net

View raw message