Re: Writing to multiple descriptors with one system call

[Sad Clouds <cryintothebluesky%googlemail.com@localhost>]

On Wed, 17 Mar 2010 21:50:45 -0400
Matthew Mondor <mm_lists%pulsar-zone.net@localhost> wrote:

> I also have a question: did your test really use non-blocking sockets
> for writing, and an efficient polling mechanism like kqueue or
> libevent used, while disabling write polling when the sendq is empty,
> enabling it back when there's data to send, and only sending data
> when a poll event indicates that write is allowed?  Otherwise, I
> assume that the LWP would lock on write(2).
> 
Yes, listening socket was set non-blocking and whenever accept()
returned a new descriptor, it was set non-blocking. All sockets were
multiplexed via kqueue.

The client was creating 5000 connections to the server and sending the
same data from a single static buffer.

The server was on the second machine, reading data from active
descriptors and discarding it. It too used kqueue, enabled read events
on connected sockets and never disabled them.

> If a "broadcast" writev(2) to multiple FDs variant existed, it
> possibly would have to present an interface similar that of kevent,
> or be tied as a new protocol over kqueue, because of the FD specific
> errors/events...  libevent for instance also supports transfer buffer
> queues and could possibly be adapted to support such a feature too.
> However I'm also unsure if this would really help or just move some
> userland and syscall overhead up to kernel overhead and achieve a
> similar overall performance.  A test implementation might indeed be
> needed, to really know :(
> -- 
> Matt

Well quite a few people seem to think this is a pointless idea. I could
think of a few cases where it could be useful, but like you said, a
test implementation is the best way to find out.