Re: >1024 connections in slapd / select->poll

["David Boreham" <david_list@boreham.org>]

> Not to work around the OS limit - to work around the unwieldiness of 
> large fdset's. This is just an application of the same 
> divide-and-conquer strategy that applies to binary search, trees, and 
> other such log(N) algorithms. Just because an OS allows a single process 
> to use thousands of file descriptors does not mean it's a good idea to 

Why wouldn't you apply the same divide and conquor strategy
inside a process ? (e.g. by using threads, or multiple descriptor
queues).

> do so. At the kernel level it's going to be more efficient to deal with 
> a cluster of average sized processes vs a single process with a huge 
> context. Eventually something is going to come along that causes the 

Interesting. Which OS are you thinking about here ?

> entire process to block, and all those threads are going to suspend, 
> doing nothing besides occupy address space, whereas a cluster of 
> processes will provide more scheduling opportunities for useful work to 
> get done; even if one process completely blocks, other processes may 
> continue.

Hmm...what you are descibing here sounds like a broken scheduler.
Do you know of any OS'es in use today that have such a scheduler ?