--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
> What about SO_LINGER? Some sockets will have the default value for
> SO_LINGER, some will have it forced off.
>
> What happens if a non-blocking socket has SO_LINGER turned on? Does the
> close fail completely, or is the socket queued for a automated close
> after the linger period (most likely)?
Hmm. There's actually conflicting reports in the manual pages.
>From Solaris 2.1
man -s2 close
If a STREAMS-based (see intro(2)) fildes is closed, and the
calling process had previously registered to receive a SIG-
POLL signal (see signal(3C)) for events associated with that
stream (see I_SETSIG in streamio(7I)), the calling process
will be unregistered for events associated with the stream.
The last close() for a stream causes the stream associated
with fildes to be dismantled. If O_NDELAY and O_NONBLOCK
are clear and there have been no signals posted for the
stream, and if there are data on the module's write queue,
close() waits up to 15 seconds (for each module and driver)
for any output to drain before dismantling the stream. The
time delay can be changed using an I_SETCLTIME ioctl request
(see streamio(7I)). If O_NDELAY or O_NONBLOCK is set, or if
there are any pending signals, close() does not wait for
output to drain, and dismantles the stream immediately.
man -s3n setsockopt
SO_LINGER controls the action taken when unsent messages are
queued on a socket and a close(2) is performed. If the
socket promises reliable delivery of data and SO_LINGER is
set, the system will block the process on the close()
attempt until it is able to transmit the data or until it
decides it is unable to deliver the information (a timeout
period, termed the linger interval, is specified in the
setsockopt() call when SO_LINGER is requested). If
SO_LINGER is disabled and a close() is issued, the system
will process the close() in a manner that allows the process
to continue as quickly as possible.
Sockets in Solaris use streams as the communication medium. On
one hand we have a close() on a socket set with O_NONBLOCK closing
immediately, and close() on a socket with SO_LINGER set not doing so,
and neither make a reference as to which takes precedence.
Short of testing, which is somewhat hard to measure and do, I'll
put out another patch which tests for SO_LINGER as well, and if that's
set, then do an aioClose for that condition too.
> Either way we lose track of a used FD until it is fully shut down.
We could always put a callback in on the aioClose() and get it
to set the FD as free once the close completes...
Cheers,
Stew.
-- Stewart Forster (Snr. Development Engineer) connect.com.au pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust. Email: slf@connect.com.au Phone: +61 3 9251-3684 Fax: +61 3 9251-3666 --MimeMultipartBoundary--Received on Tue Jul 29 2003 - 13:15:49 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:47 MST