On Thu, Mar 18, 2010 at 1:10 AM, Sad Clouds <cryintotheblue...@googlemail.com> wrote: > On Thu, 18 Mar 2010 00:53:26 +0100 > Jean-Yves Migeon <jeanyves.mig...@free.fr> wrote: > >> On 03/17/10 17:53, Sad Clouds wrote: >> > 1. Accepting connections >> > >> > On busy web server it is likely that the listening socket will have >> > multiple entries on the completed connection queue (i.e. established >> > state). You call accept() in a loop until you get EWOULDBLOCK and >> > since these are new connections, the chances are all these sockets >> > contain HTTP GET requests for /index.html >> > >> > Instead of calling write() 50 times for all 50 new sockets, you >> > could just call write2v() once. >> >> So basically, between the 1st accept(2) and the last, all the clients >> are waiting for input (which they will get sequentially, when you >> will perform your write2v() after the _last_ accept(2)). >> >> Which means that the 1st "accepted" filedes created will wait for the >> 50th to be accepted. Seems inefficient for me. > > This is what high performance servers do. There is nothing > "inefficient" about it. You set the listening socket non-blocking and > call accept() in a loop.
Since you're already worried about context switches, it's better to watch the accepting file descriptor for read events and block in kevent(). -- Good, fast & cheap. Pick any two.