|
|
James Yonan wrote: > > I must admit that I have been working on a general purpose I/O event > > library that uses poll/epoll/select, for another application, and it > > would never have occurred to me to call poll/epoll/select in the first > > place for a socket which has shown no sign of blocking! > > In some cases, you need to block on write with poll/epoll/select in order > to prevent write overruns, for example when TCP sockets are being used. > In other cases, an OS could communicate the fact that an internal outgoing > UDP queue is full by passing a write-blocking indication to userspace. So > it makes sense from a flow-control perspective not to throw away this > information. Yes, flow control is useful, but you don't need to call poll/epoll/select _until_ the operating system returns EAGAIN on a UDP/TUN/TAP socket, or a short write on a TCP socket. The idea is to maintain a flag per socket saying whether the next write is likely to succeed or return EAGAIN. After a write to any socket type returns EAGAIN, or after a short write if it's TCP, you would set that flag. After a successful write, you would clear that flag. You would include the socket in the poll/select/epoll set at the next check only if that flag is set for the socket. (For epoll you might optimise further to eliminate calls, but that's complicated to describe). That gives a nice reduction in system calls while still doing proper flow control. Is there a problem with doing this for OpenVPN-style tunnelling that you know about? -- Jamie |