Hi,
On Thu, 02 Mar 2000 10:26:43 -0800, Dan Kegel <dank@alumni.caltech.edu>
said:
> sct's stance on race conditions between close(), accept(), and sigwaitinfo()
> in sigio-based programs can be summed up as "Oh, don't worry about
> ghost events, you should be prepared for read() to return
> EWOULDBLOCK".
You *have* to be able to expect EWOULDBLOCK.
If you use poll, and you fail to read all the data which is available,
then next time you poll you'll find the fd still active. If you rely on
signals, then it is up to you to make sure that you do all of the work
specified by the signal, and that absolutely requires that you keep
reading until there is no more data on the fd.
> This works for POLL_IN and POLL_OUT events. But Julian points out that
> it might be hard to ignore POLL_ERR and POLL_HUP events in the same way.
POLL_ERR should always be associated with an error return the next time
you do a read(), shouldn't it? As for POLL_HUP, that works fine as a
marker as long as there is precisely one HUP generated per fd lifetime.
If that's not the case, then extra synchronisation would indeed be
necessary to parse the stream perfectly.
> Maybe we do need marker events for fd creation and/or deletion after all...
> sct, what say ye?
If you need marker events in the stream, then you can put them there
yourself when you accept or close a socket. sigqueue() will let you
place your own siginfo into the rt signal queue, and that siginfo will
be quite distinct from the ones generated by SIGIO, so they will work
perfectly well as placeholders.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:15 EST