lkml.org 
[lkml]   [1999]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Mark Russinovich's reponse Was: [OT] Comments to WinNT Mag !!
Date
From
>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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.039 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site