Messages in this thread | | | Date | Thu, 02 Mar 2000 10:26:43 -0800 | From | Dan Kegel <> | Subject | re: Changes in the sockets: SIGIO handling |
| |
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". 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.
Maybe we do need marker events for fd creation and/or deletion after all...
sct, what say ye?
- Dan "Chicken Little" Kegel
Julian Anastasov <uli@linux.tu-varna.acad.be> wrote: > With current behavior, when we receive POLL_HUP we know > that the remote end closed its end of the connection. But what > if we can't wait remote end to close the connection and we close() > the socket, even after shutdown(fd,1). After our close() when the > fd is released and can be reused again it is still possible unread > events to stay in the rt queue (POLL_IN in this case). When we > create/accept new file descriptor (with the same value) and continue > to read the events (from the long long rt queue) using sigwaitinfo(), > we can dequeue unexpected notifications for the old file descriptor. > > For example: > > <-- POLL_IN for fd > sigwaitinfo(): POLL_IN for fd > read(fd)=100 > // We remember that we can write(), so we try to write() > write(fd)=100 > shutdown(fd,1) > // We wait remote end to close > // Here we expect POLL_IN but it is not received (after some > // timeout) > <-- POLL_IN for the listener enqueue > <-- POLL_IN/POLL_ERR enqueued after our last check of > the rt queue > // We decide to close(fd) > close(fd) > sigwaitinfo(): POLL_IN for the listener > fd = accept() > set fd FASYNC, ... (or inherited from accept) > sigwaitinfo(): POLL_IN/POLL_ERR for the old fd but we think it > is for the new fd. Not fatal, one extra read()=EAGAIN > > What if we receive POLL_ERR from old fd when the new fd is > in connecting state? We think the connection failed for the > new fd. FATAL!
- 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/
| |