Linus Torvalds wrote:
>
> The point they disagree is when the event gets removed from the event
> queue. For edge triggered, this one is trivial: when a get_events() thing
> happens and moves it into user land. This is basically a one-liner, and it
> is local to get_events() and needs absolutely no help from anybody else.
> So obviously event removal is _very_ simple for edge-triggered events -
> the INTACK basically removes the event (and also re-arms the trigger
> logic: which is different from most interrupt controllers, so the analogy
> falls down here).
And IMHO here's a problem. The events are no longer events. They are
just hints saying: after the previous get_events() something has happened.
You don't know if you've already handled this event. There's no synchron-
ization between what the app does and the triggering of 'hints'.
For example your waitpid-loop: you get the event, start the waitpid-loop.
While processing another process dies. You handle it too (still in the
loop). But a new 'hint' has already been registered. So on the next
get_event you'll be notified again. I just hope, every event-generator
has a WNOHANG flag...
It could even be possible, that you are unable to perform some actions
without triggering hints despite the fact that the conditions will
already be gone before the next get_event. May generate lot of bogus
hints.
At least the current semantic of for example "POLL_IN on fd was signaled
so I may read without blocking" gets lost.
Maybe (don't know kernel wise) it makes sense to check in the kernel
if the events to be returned to userspace are still valid. The user
space has to do it anyway... But that way you get a more level-based
design ;)
Another thing: while toying with cooperative userspace multithreading
I found it much more versatile to have a req_type/req_data tuple in
the request structure (ie READ/<fd>, TIMEOUT/<ms>, WAKEUP/<handle>).
Ciao, ET.
-
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/
This archive was generated by hypermail 2b29 : Tue Oct 31 2000 - 21:00:15 EST