dean gaudet wrote:
> suppose you're building a threaded server to scale to 20k connections,
> and you want to support fork()/exec() of CGIs dirctly (rather than
> through a separate daemon process).
>
> if you don't use close-on-exec, then after fork before exec you have
> to iterate over the 20k descriptors to close them all -- or you have
> to walk your own data structures (a list of open sockets) to find what
> descriptors are open and close them.
> if you use O_CLOEXEC then it's not possible for an fd to be open which
> isn't marked to be closed on the exec, and so you've no extra work to
> do before exec.
>
> but if you try to use FD_CLOEXEC there's a critical section between
> the open/socket/accept/pipe/... and the fcntl(). you pretty much have
> to put it under a semaphore (although you can get away with a rwlock),
> or iterate over all the descriptors.
Yes, this is the worst part. Having to synchronise threads.
> i've a hairbrained idea for replacing fd integers with pointers which
> might actually scale better if anyone wants to hear it again.
Completely hairbrained, would make no difference to scalability, and
make accessing your user space data structures slower. (Think X window
ids and the need to use a hash table instead of a flat table).
O_ANYFD would, in principle, improve scalability. It was proposed a few
years ago -- it means "kernel can return any fd, not necessarily the
next free one". I don't think it was considered worth the effort.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
