epoll and half closed TCP connections
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hello!
Quoted 2 lines
it looks as though _every_ TCP ACK you receive will cause epoll to wake up a task which is interested in _any_ socket events,
This is not quite true. sk->write_space() is called only after write queue is full, and it is exactly one wakeup until the next overflow.
But, actually, yes, it is right observation: one wait queue for all the socket events is painful. Note, that with current poll() improvements are suboptimal, tcp_poll() does not know _what_ this poll polls for, so it has to stand in all the wait queues. The same thing kills lots of possible improvements.
Quoted 2 lines
further, we might as well admit that POLLHUP should be called POLLWRHUP.)
No, really. POLLHUP=POLLRDHUP&POLLWRHUP, plus POLLHUP is unmaskable event. Yes, SVR4 screwed up its semantics in such extent that it is mostly meaningless.
Alexey
Quoted 11 lines · On Mon, 14 Jul 2003 [email protected] wrote:
Quoted 2 lines
it looks as though _every_ TCP ACK you receive will cause epoll to wake up a task which is interested in _any_ socket events,
This is not quite true.
sk->write_space()is called only after write queue is full, and it is exactly one wakeup until the next overflow.But, actually, yes, it is right observation: one wait queue for all the socket events is painful. Note, that with current
poll()improvements are suboptimal,tcp_poll()does not know _what_ this poll polls for, so it has to stand in all the wait queues. The same thing kills lots of possible improvements.
Indeed. This can be improved though, with some serious work. The poll(2) and epoll caller supply events he is interested in. We could have poll_wait() (and f_op->poll()) to accept an events parameter so that the f_op->poll() code can drop inside separate wait queue depending on what the caller is waiting for.
- Davide