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 ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
