Having done some (but admitedly, not very much) win32 programming with a
similar event interface, I have mixed feelings about this. For this you get
a unified interface and the ability to have a single thread wait for
conditions of various types. The unified interface does make it more
difficult to determine what is happening locally (just look at a win32
code segment and see a WaitForMultipleEvents() call and try to trace
you way around to see what events are being passed around). Waiting
for different types of unrelated conditions does mean you can get away
with more single processing, but is usually not that useful, since many
times these events are being generated by other threads, so you kinda
defeat the purpose. So it is usually done better with multiple threads
waiting seperately.
What you also make more difficult is extending the semantics of the call
without burdening many people who don't really care about the changes. For
I/O you just want to wait for anything to come in, but for thread termination
you may either want to wait for a single thread to terminate or all of
the threads you are interested to terminate. This added complexity is
useless in the I/O cases and should not impact it. Also, event arguments
become more complex. You either have the event struct be a union of
various types (ugh) or you have a descriptor and wait event flags in which
case you destroy some of the ability to type check the call (especially since
both file descriptors and thread ids tends to start at 1 and increment).
>This would mean a change to declare_interest so that it can accept
>parameters
>other than a file descriptor and to the event_descr_t so that it can
>report
>events other than those related to a file descriptor.
>
>Regards
> Joerg
>
I may be biased since I think that select() is fine and efficiently
implementable. It is also very simple, which is good. A general purpose
event call will never be able to work for *all* events well (if you have
user fired events, too, then this would never be possible), so I think
that seperate event queues make more sense, are easier to implement
efficiently, and are easier on the user in the long run.
-jason
-
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/