> Dean Gaudet writes:
> > You have to issue a read() or an accept() in order to cause those events to
> > even appear on the pipe. The read/accept return immediately and later on
> > they complete and the results appear on the pipe. So none of the problems
> > you mentioned happen.
>
> ??? So how does my application know that data has arrived on a TCP
> connection? Do I call poll(2)? Or do I speculatively call read(2) on
> all connections? The latter seems the most promising.
speculatively call read(2). You see the way I'm really envisioning using
this is to have a user-level threads package which hides the low level
read(2) call -- when the call happens the (user) thread issuing it is
blocked. The kernel thread that was running that user thread then bops
back and reads the event pipe, the event it receives is essentially a
completed i/o for another user-level thread, and it starts running that
user-level thread.
You code as if you're working with a blocking read() except the only thing
that "blocks" is your user level thread, in that it gives up its slice
when it does i/o.
But I'm sure what I proposed has problems ... and I need to go read more
POSIX to check out if the other suggestions can do the same thing.
Dean