Messages in this thread | | | Subject | Re: Mark Russinovich's reponse Was: [OT] Comments to WinNT Mag !! | Date | Wed, 05 May 1999 09:42:16 -0400 | From | Paul Barton-Davis <> |
| |
>From: markcn@tiac.net (Mark Christiansen)
>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/
| |