| |||||||||||||
select() actually IS edge triggeredselect() actually IS edge triggeredPosted Mar 16, 2003 19:00 UTC (Sun) by Ross (subscriber, #4065)In reply to: select() actually IS edge triggered by IkeTo Parent article: Edge-triggered interfaces are too difficult? Yes, I have seen this happen "in real life" on several systems including Linux. The information given by select() is just a "snapshot" in time. You seem to be claiming that this is something new with edge triggered notification. It's not. You point out the case I'm talking about: accept(), but the problem isn't caused by reading or writing more than once. In fact, if you use blocking sockets, there is no way to avoid the problem. Specifically, I was talking about connections which are canceled between the call to select() and the call to accept(). The problem in general is that things can change between those two system calls. If a connection is made to a server with a blocking listen socket the server will be notified of that new connection by select(). But the client can then cancel the connection before the server calls accept(). If there are no other waiting connections, the server will block until another connection is made. This is a classic race condition like the signal right before select() race and the alarm() without sigsetjmp() race). Most systems do not prevent this from happening (though a few will keep dead sockets in the accept queue so they can be handled as errors by accept).
(Log in to post comments)
|
|||||||||||||