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.mig...@free.fr
