I have done a lot of work in win32 using WaitForMultipleObjects()
and find it to be invaluable. My work involves controlling a machine and
image recognition on that machine's output in soft real time. There are
a great many things that can happen asynchronously and WaitForMultipleObjects
allows me to handle them without needing to have a thread for every possible
event. The code winds up working like a GUI event handler. Read the next
event and dispatch the code that deals with it. Adding a new event requires
only an entry in a data structure and a handler function.
Even if I needed a thread for every device and data path I would still want
an asynchronous path in to each thread for control messages. When a thread
reaches for its next event one of the results it can get is a message telling
it to stop what its doing, close up shop cleanly and reinitialize.
>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).
This is purely a coding style issue. Coding select() is just as obscure.
> 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.
??? Why does it matter if events are generated by other threads? Are you
referring to the thread limitations imposed by the win32 GUI? Not using
the GUI I have not encountered any circumstances where I could not arrange
for event handling where it was most natural. When are multiple threads
waiting separately simpler?
>
>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).
It is not necessary to have a "wait for all" style. This can be done just
fine by a user space wrapper function if needed.
I always thought select() was as ugly as they get. A new system call with
new arguments would be needed.
>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.
Ouch. This gets me a LOT of threads.
Mark
-
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/