Hi!
On Thu, Nov 08, 2007 at 02:19:25PM -0800, Christopher Layne wrote:
>On Thu, Nov 08, 2007 at 08:11:55AM -0800, Garth Patil wrote:
>> http://sfbay.craigslist.org/pen/cpg/472325599.html
>> libevent programmer wanted (san mateo)
>> - NOT BLOCK ON ANY STEP
>close() can block. *boom tsst*.
On sockets, IIRC only with non-standard settings of the SO_LINGER
option.
The setsockopt(4) manual page, on OpenBSD, says:
SO_LINGER controls the action taken when unsent messages are queued on
socket and a close(2) is performed. If the socket promises reliable de-
livery of data and SO_LINGER is set, the system will block the process on
the close(2) attempt until it is able to transmit the data or until it
decides it is unable to deliver the information (a timeout period mea-
sured in seconds, termed the linger interval, is specified in the
setsockopt() call when SO_LINGER is requested). If SO_LINGER is disabled
and a close(2) is issued, the system will process the close in a manner
that allows the process to continue as quickly as possible.
And IIRC, SO_LINGER *is* disabled by default. So if you want close not
to block, you either keep SO_LINGER disabled or set the linger timeout
to zero (which specifies *different* behaviors!).
And then, for HTTP, this should be relatively irrelevant, as usually the
client (and the task specified was a HTTP *client*, not a server)
closes the connection only after receiving the response, and the
server even only *starts* sending the response after having received
the whole request, so the transmit buffer of the socket should be empty
anyway when the client closes the socket.
Kind regards,
Hannah.
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
