>Yes, I did this as a test and was impressed that the performance was comparabl
>e
>to what I get in NT. I expected the Unix domain sockets I was using to cost
>a lot more time than they did. Even so the code complexity was unwelcome.
>Look at any GUI. They all multiplex the keyboard, mouse and window events
>so you read just one input source. To duplicate what I do with WaitForMultipl
>eObjects
>in NT I would need 13 threads in just one of my processes. All of those threa
>ds
>would probably just grab a process wide lock as soon as they come unblocked
>to save me from analyzing all of the potential concurrency.
I don't think so. You just use pipe and non-pipe fd's as your only event
sources, and do a single select on the whole set. Then make the
appropriate callbacks for any events on each fd. I have a
multithreaded app that does just this, and the only locks it needs to
grab in connection with event handling is for genuinely process-wide
structures (like the UI request queue, and the error message queue).
At first, I was really annoyed that you couldn't select on a
semaphore, but I eventually saw that pipes gave me everything the
semaphores did (for this purpose, anyway - i'm using pthreads for
actual inter-thread synchronization).
--p
-
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/