Re: Linux select command issues


Logan Shaw wrote:

Is there any reason to assume you have to write your program with
the assumption select() is always passed valid sets of file
descriptors? I don't see why it's invalid to do your select(),
then after it returns, double-check any descriptors (by referring
to some data structure of your own) to see if they still refer to
what you thought they did. As long as you check a superset of
the descriptors you actually need, you should be OK.

If a file descriptor has been closed and re-opened and isn't what
it was before, as long as you track that and are aware of the fact,
there is no harm in having been notified of some condition on that
file descriptor. It's just superfluous information, which is
harmless if you recognize it as such.

It comes down to whether or not 'select' is a pure status reporting
function. If it's a pure status reporting function, there is no harm is
asking the status of something in which you have no interest. However,
if 'select' was more than a pure status reporting function, then
'select'ing on something that wasn't yours could cause problems.

Consider, for example, a hypothetical system on which a 'select' hit
for write actually guaranteed that a subseqent write would not block.
What would happen if you 'select'ed for write on a socket that wasn't
yours (say because the descriptor was yours recently), and then the
thread that owned that socket did a 'write' that it expected to block
but then *surprise* didn't block?

So you are correct if and only if 'select' is a pure status-reporting
function that cannot change or affect the semantics of operations after
it.

Some have argued that a 'select' hit for readability on a UDP socket
prohibits the implementation from dropping the datagram that it
reported (or else a subsequent 'read' could block). If you believe
that, then 'select' is not a pure status-reporting function. However,
this status change, AFAICT, can't harm anything. But if it can perform
status changes that are harmless, perhaps it can also perform status
changes that are harmful.

DS

.

Relevant Pages

  • [patch] SOCK_CLOEXEC, SOCK_NONBLOCK and MSG_CMSG_CLOEXEC
    ... MSG_CMSG_CLOEXEC to recvmsgmakes file descriptors ... I do not pass the SOCK_* flags to MAC because this may cause incorrect ... +.Xr socket 2, ...
    (freebsd-hackers)
  • Re: reading a fixed-length message
    ... properly (close the socket, serial port, etc.) ... depending on the descriptors you are using. ... if serialfd for write ...
    (comp.unix.programmer)
  • Re: Linux select command issues
    ... the assumption selectis always passed valid sets of file ... double-check any descriptors (by referring ... If it's a pure status reporting function, ... mean you couldn't write a correct program knowing these side effects ...
    (comp.unix.programmer)
  • are socket handles always usabele by file i/o functions?
    ... descriptors are IFS handles by using these descriptors ... I thought that if I create socket from WSAPROTOCOL_INFO which has not ... But it's written that if SPI does not create IFS handle, ... can read that it returns handle that can be used in file I/O functions. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Sockets and threads...
    ... Mark Seger wrote: ... Are you opening sockets "internally" from one ... I had tried to share descriptors and failed ... That only works if you only need to write on the socket. ...
    (comp.lang.perl.misc)