RE: OTEnterNotifier
RE: OTEnterNotifier
- Subject: RE: OTEnterNotifier
- From: "Tim Dorcey" <email@hidden>
- Date: Tue, 21 Mar 2006 21:23:45 -0800
- Importance: Normal
> It turns out that my reading of the code in 2004 was more accurate.
> OTEnterNotifier disables event processing (including timers, deferred
> tasks, and provider notifications), and this includes a wait for the
> event delivery thread to stop.
Thanks for delving into ancient issues.
> >context of that same thread. When I upgrade to BSD sockets,
> I guess can
> >implement with network thread using select with 10 msec
> timeout to do high
> >priority periodic work.
>
> Sounds reasonable. Of course, you should be using kqueues, not
> select, but you knew that, right? (-:
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? Main
concern for me would be how responsive it is to 10 msec timeout, which I
guess would depend mainly on thread priority?
>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? If so, what would be quickest way for the pthread to wake up the
main thread, assuming main thread is sleeping in WaitNextEvent()? Or, am I
going to find this easier if I use MP Thread API (which I know nothing
about)?
Tim
_______________________________________________
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