RE: OTEnterNotifier
RE: OTEnterNotifier
- Subject: RE: OTEnterNotifier
- From: Quinn <email@hidden>
- Date: Wed, 22 Mar 2006 11:01:49 +0000
At 21:23 -0800 21/3/06, Tim Dorcey wrote:
Actually, I didn't. But, you knew that, right :-). From a quick look at
kqueues, it seems that main advantage is in monitoring a large set of
events. In my case, I will just be waiting on a single UDP port (and my 10
msec timeout). Would there be any advantage to kqueues in that case?
kqueues are better in all cases. Unless you're writing code that
needs to run on old versions of Mac OS X (or other platforms, that
don't support kqueues), use kqueues at a matter of course.
Main concern for me would be how responsive it is to 10 msec timeout, which I
guess would depend mainly on thread priority?
Whether you use kqueues and select makes no difference here.
[...] am I going to find this easier if I use MP Thread API (which I
know nothing about)?
IMO you should never use the MP thread API unless a) you're built
CFM, and thus don't have easy access to pthreads, or b) you need to
run on traditional Mac OS. In all other cases, use pthreads.
The reason is that the MP thread library is built using pthreads.
There's almost no benefit to using it, and there are a number of
negatives (ranging from the trivial (more overhead) to the exciting
(MP threads have weird latency issues because the MP library keeps
some global locks in order to maintain the traditional Mac OS
semantics)).
From my reading of TN2028, I could go ahead and create a pthread within my
Carbon (Mach-O) application to manage socket read and periodic task. Then,
I could use pthread_mutex where I need synchronization with my main Carbon
thread?
That would certainly work.
If so, what would be quickest way for the pthread to wake up the
main thread, assuming main thread is sleeping in WaitNextEvent()?
There are a gazillion ways of doing this [1], and the differences
between them don't amount to much. As such, I haven't come up with a
strong opinion as to which to use.
OTOH, faced with this situation I would probably just use CFSocket
(or one of the higher-level CF APIs). This provides
socket-to-runloop integration so that you don't have to. It takes
care of forking a thread to listen on multiple sockets, and
communicating the results to the main thread in an efficient manner.
Combined with CFRunLoopTimer, you get a nice event-driven networking
on your main thread.
[1] A few that spring to mind are:
o CFRunLoop event sources
o CF timers
o a UNIX domain socket pair wrapped with CFSocket
o Carbon events
o -[NSObject(NSMainThreadPerformAdditions)
performSelectorOnMainThread:withObject:waitUntilDone:modes:]
o MPRemoteCall
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden