> 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).
Or threading is a workaround for lack of proper nonblocking I/O handling
in applications. Multithreading and nonblocking I/O are two opposite
concepts when it comes to I/O handling.
> 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.
Nothing is "intuitive". Everything mostly depends on habit and amount of
trouble, processing model creates for a programmer.
> 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().
accept(2) means that system call is mentioned, and not a wrapper over it
that exist in userspace threads implementations.
-- Alex
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu