> Seems like an odd requirement, but I haven't looked at the Apache
> source much yet. I can understand not wanting to handle EINTR
> everywhere, but why do you need it around accept? Why not use the
> async mode?
HTTP browsers expect every connection that connects to deliver at least
one response. If you don't deliver one response then the browser will put
up "document contains no data" or a similar message. (But later on,
during a persistant connection you can read an entire request and ditch
the socket before responding, the clients have to expect this due to
network delays and server timeouts.)
Apache uses SIGUSR1 to indicate that a "graceful" restart should be
performed -- the children who are in between requests should die
immediately, and the children who are serving requests should die at the
end of the request. The parent rereads the config and forks new children
1-for-1 as the old die off.
So the child has to expect to receive a SIGUSR1 at any time. Unless it's
in the main loop waiting for another socket or request it wants to ignore
the signal... and since I don't trust libc code or module code to do the
right thing with EINTR in all cases I either need SIGUSR1 set to SIG_IGN
or I need it with SA_RESTART. (There's a bit of shared memory that the
child can use to discover when it should be terminating if it ignored the
signal, or if it's on a box that doesn't have reliable signals.)
When the child is in the main loop at the accept() it needs the accept()
to be interruptible, otherwise it will be stuck in accept() when it's
really supposed to die off. So it needs a SIGUSR1 handler without
SA_RESTART. Here's where I tried to have a SIGUSR2 handler without
SA_RESTART and have my SIGUSR1 handler raise(SIGUSR2) to attempt to
interrupt the accept() ... but it doesn't work (on linux or on solaris,
which means I can't even consider it as a portable solution so I'm trying
to find another).
Yeah I could mark the socket non-blocking and use select. But that would
be an extra syscall per connection.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu