Re: What to do without OTScheduleSystemTask?
Re: What to do without OTScheduleSystemTask?
- Subject: Re: What to do without OTScheduleSystemTask?
- From: Quinn <email@hidden>
- Date: Tue, 30 Mar 2004 09:40:12 +0200
At 13:17 -0800 29/3/04, Graham Parkinson-Morgan wrote:
For Mach, I presume (please correct me if I am wrong) that
OTNotifier is not really called in interrupt space at all, and I
can pass the packets I receive direct to the packet processors.
It's true that under Mac OS X OT notifiers aren't called from a true
interrupt. In fact, they're called from a preemptive thread that
Carbon uses to synthesise interrupts. However, this can still
present some tricky problems. For example, if you're packet
processor wanted to do any UI, it would run into problems because the
UI layers can't be called from a preemptive thread.
In summary, you may still need your "defer to system task time" code.
But for Carbon apps, I presume that OTNotifier is still called in
interrupt space but the OTScheduleSystemTask has been retired. If
this is the case I need another strategy to process at 'system task'
time the packets received at interrupt time: but so far the only
strategy I can come up with is polling at idle time (I regard a
cooperative thread here as amounting to the same thing).
There are a bunch of different approaches you can take, but none are
as simple as OTScheduleSystemTask.
1. WakeUpProcess -- If you have a WNE based application, you can do
use the same queue mechanism and poll the queue from your even loop.
Then, when you put something into the queue you call WakeUpProcess
which causes your event loop to run with a null event.
2. PostEventToQueue -- IIRC PostEventToQueue is interrupt safe even
on traditional Mac OS. Thus, you can create an event at system task
time and hold on to it in a global variable. From your interrupt
code you can post it to the main event queue. The event handle can
then process your queue of packets.
3. MPRemoteCall -- This won't work on traditional Mac OS but is a
fine strategy on Mac OS X.
On a more general note, I strongly recommend that you think about
what your packet processing objects need to do and provide a clear
specification to the authors of those objects as to what routines
they can call. Otherwise you can get into all sorts of trouble as
the packet processors try to put up UI or other crazy things.
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.