> 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.
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:
============================================================================
===
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.
S+E
============================================================================
===
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?
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.
Tim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macnetworkprog/email@hidden
This email sent to email@hidden
