> In article <Pine.LNX.3.96dg4.990506091503.9238G-100000@twinlark.arctic.org>,
> Dean Gaudet <dgaudet@arctic.org> wrote:
> >
> >Last time I brought up wake-on accept(), Alan said it is a hard problem.
> >Maybe wake-one fcntl() is easier.
>
> No, wake-on-accept is the _much_ easier one, please don't use fcntl
> locking.
For a single listening socket, what you say is feasible. For multiple
listening sockets, with multiple tasks using accept() we really need
some other wake-one interface outside of accept().
Suppose multiple tasks go into select() to find a socket which is ready
to accept. When a connection arrives on one of the listening sockets,
all the tasks are awakened. Then they all rush to the accept().
One succeeds. If the listening socket is blocking, the rest are stuck
in accept(), and the webserver is somewhat screwed (because it now has
a bunch of children blocked in accept() on some arbitrary socket which
may not get another request for days).
If the listening sockets are non-blocking, all the children rush back
up to select()... and all we've accomplished is extending the wake-all
loop from kernel to userland with an extra syscall to boot.
Dean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/