RE: So, Poll is not scalable... what to do?

["David Schwartz" <davids@webmaster.com>]

> If poll is not scalable, which method should I use when writing
> multithreaded socket server?

	'poll' is quite scalable. It's only not scalable if you make stupid
assumptions about how people use it.

> What is the most efficient model to use?
>
> Is there a "standard" model to use when writing a scalable multithreaded
> socket serve such as "io completion ports" on windows?

	If all your sockets are equally active, having a bunch of threads each
'poll'ing 1,024 descriptors is perfectly scalable. 64,000 is not a problem,
and that's about the kernel limit if memory serves me.

	If you have active and inactive sockets, sort them. Have some threads that
'poll' on large numbers of inactive sockets and some that 'poll' on small
numbers of active sockets. This will scale quite well as the expensive
'poll' calls are infrequent compared to the cheap ones.

> From the "Microbenchmark comparing poll, kqueue, and /dev/poll",
> kqueue is
> the way to go. Am I correct?

	Yes, if you're using a kernel that supports it. It will pretty much always
be more efficient than 'poll'.

> Also, why is it that poll doesn not return with "close signal" when a
> thread-1 calls poll and thread-2 calls close on a sockfd1? It seems that
> poll only handles close signal when a client disconnects from the server.
> I've seen this mentioned here before, has it been fixed?

	You can never ever make this work. There will always be a race condition no
matter what you do. (How can you ever be sure thread-2 doesn't all 'close'
jsut before thread-1 calls 'poll'?) So do not ever do this. Do not ever
release a shared resource while a thread is or might be using it because it
might also be about to use it!

	DS