Re: Thread implementations...

Mike (ford@omnicron.com)
Fri, 19 Jun 98 11:52:26 -0700


> > The problem, for one, with web etc. servers is the incoming connection
> > socket. If you could tell select/poll "hey, when a new conn comes in,
> > wake up one of us", poof this issue would be solved. However the
> > defined semantics for these interfaces says to wake everyone polling
> > on it up.
>
> Apache handles this very nicely. It runs a group of processes,
> and each *blocks* on accept(2). When a new connection comes in,
> the kernel wakes up one, which handles that socket alone, using
> blocking I/O (it uses alarm(2) to do timeouts).

This demonstrates the point that select and poll are workarounds for
the lack of threading support in Unix. They aren't needed if you use
a threads facility (or a separate process for each thread you need).

Once you have threads you can stick to the intuitive synchronous model
of system calls, which has always effectively handled waking one of
multiple waiters.

Off topic, I would like to pick a nit:

accept() is a system call. accept(2) is not a system call, it is a
manual page. One doesn't block on accept(2), one *reads* accept(2)
to find out how to use accept().

-=] Ford [=-

"Heaven is exactly like where you (In Real Life: Mike Ditto)
are right now, only much, much better." ford@omnicron.com
-- Laurie Anderson http://www.omnicron.com/~ford/ford.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu