On 03/18/10 01:10, Sad Clouds wrote:
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. Any connections that have completed 3-way handshake will be on the socket's ready queue and will be returned to you straight away.
Pretty much all servers use the accept loop thing and fork/pthread right after, but this was not my point. Do you expect to have accept2() that returns an int *, a close2() to close multiple filedes at a time, and so on? BTW, how many accept() are you going to have before finally using the write2v()? 10? 50? 500? You assume that the client is stateless too.
Having 80% system time passed in write() calls is not negligeable, but if you send the data byte after byte, I hardly see why it would be the syscall's fault here. You will have to assess that the overhead does indeed come from the context switch, and not by queuing up packets for the PHY, block I/Os, or moving data around the IP stack. There is a big mess behind a write(2), and the context switch is just one small part of it. Instrument. "You can't control what you can't measure."
-- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost