RE: OTEnterNotifier
RE: OTEnterNotifier
- Subject: RE: OTEnterNotifier
- From: Quinn <email@hidden>
- Date: Tue, 21 Mar 2006 11:35:35 +0000
At 12:56 +0100 29/4/04, Quinn wrote:
At 22:49 -0400 28/4/04, Miro Jurisic wrote:
If a thread calls OTEnterNotifier for an endpoint, and the notifier
for that endpoint is currently executing in a secondary thread,
OTEnterNotifier will not return before the notifier returns.
I've always assumed this to be true. A quick look through the
source supports that assumption.
At 11:22 +0000 20/3/06, Quinn wrote:
OTEnterNotifier does not block waiting for notification routines to
complete, or anything like that. It simply sets a flag that
prevents further notifications from being delivered. These queued
events are deferred until you call OTLeaveNotifier.
At 9:06 -0800 20/3/06, Tim Dorcey wrote:
Thanks. I got the impression that calling OTEnterNotifier would prevent the
caller from pre-empting the notification routine from an earlier exchange on
this list [see above]
Ah, you're right, my statements are self-contradictory. Whoops.
Sorry about that.
[The following applies to Mac OS X only, of course...]
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.
However, there is a wrinkle (which is what confused me this time
around). OTEnterNotifier only disables event delivery if you call it
at system task time. The exact definition of what OT considers to be
"system task time" is quite complex.
In TN2028, there is a section on "Carbon and Interrupts," which suggests
that each subsystem creates only 1 interrupt emulation pthread for a given
process. I wonder, if I move my code that currently runs in a TimeManager
task and a DTInstall into an OT TimerTask and OT DeferredTask, might I get
automatic serialization with Notification routine?
I expect that you would. However, that's relying on the
implementation details of the OT library, not on its stated API.
Admittedly, the OT library is unlikely to change in any significant
fashion ever again. Still, sounds like skating on thin ice to me.
IMHO it would be much better to do the serialisation yourself.
That would really be the right architecture, to have a single high priority
thread that blocks waiting for data coming in off the network, but also
wakes up about every 10 milliseconds to do some time-triggered work in the
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? (-:
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