lkml.org 
[lkml]   [2000]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: O_CLOEXEC (was Re: thread rant)
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 majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.463 / U:0.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site