On 10/19/2010 4:31 AM, Larry Ducie wrote:
I would like to know if anybody knows what will happen to a socket
descriptor if alarm is used as a timeout mechanism.
That depends on what you do when the signal is received. In general, if
a socket API is blocked, waiting for the network, then the API will end
and return -1 with errno=EINTR (interrupted by signal).
If, for example, we have the following scenario:
alarm(1);
call routine to post some data via a socket (via a httpapi routines)
alarm(0);
Why not specify the timeout parameter on the HTTPAPI request?!
HTTPAPI isn't just reading/writing a socket, it's doing many additional
calculations. Furthermore, it uses non-blocking sockets, so it'll never
block on a network event. It'll sit on the select() API when it's
waiting for the network, and select() has it's own timeout mechanism.
You can control that timeout by passing a number of seconds in the
appropriate parameter.
Assuming the alarm is fired due to the post taking more than a second
to complete, what would happen to the socket descriptor? Does it get
closed when interrupted or do we have a leak here?
It depends on what HTTPAPI is doing at the instant when the signal is
received, and what your signal handler does.
If HTTPAPI happens to be calling a socket routine when the signal is
received, the socket routine (connect, recv, send or most likely select)
will return with rc=-1, and errno=EINTR. HTTPAPI will detect that as a
network error, and will *try* to close the socket and report an error to
your program. But it's at the mercy of your signal handler.
If HTTPAPI happens to be doing a calculation, parsing XML, etc, then it
may not detect the signal at all. (HTTPAPI does not have any signal
handlers defined in it.) in that case, it will *try* to continue along
it's merry way, and pay no attention to the signal whatsoever.
The reason I emphasize *try* is because your signal handler has the
ability to kill the HTTPAPI code entirely, and return control back to
it's caller. If you do that, then the socket will certainly remain open.
We are getting some jobs with the dreaded "too many open files for
process" error and I'm wondering if this code could be the culprit.
Maybe. I strongly recommend that you never use alarm() to try to stop
HTTPAPI from processing. It's not designed for that. I certainly do
not support it -- of course, you have the source code, you can choose to
support anything you like.
midrange.com
