Re: [OpenTransport] debugging my NotifyProc callback
Re: [OpenTransport] debugging my NotifyProc callback
- Subject: Re: [OpenTransport] debugging my NotifyProc callback
- From: Quinn <email@hidden>
- Date: Sat, 6 Dec 2003 08:50:59 +0000
At 14:02 -0700 5/12/03, Thomas E. Knowlton, Jr. wrote:
Can anyone comment on this approach?
It's a fine approach, for debugging. I used it extensively in OTMP.
<
http://developer.apple.com/samplecode/Sample_Code/Archive/Networking/OTMP.htm>
In "OTMP.c", look for the routines QueuingBlueNotifier and
RunBlueNotifications and their associated comments.
You should be warned that this approach has two drawbacks.
1. It slows things down significantly. If you want high performance,
you'll need to use real notifiers (at least for events on the fast
path).
2. It masks errors. There are two basic reasons for this: a) all of
the events are now executed at system task time, and hence
serialised; and b) things execute slowly, and thus you get fewer race
conditions.
What I did for OTMP was to use this approach for initial bring up and
then, for performance and stress testing, switch to my real notifier
code.
Got a better idea for gaining reliable high-level debugging for the
NotifyProc?
Logging. Once you've ironed out most of the bugs using a system task
time notifier, the remaining bugs will be the gnarly time-dependent
ones. These will be affected by stepping through with the debugger
so, even if you could debug the notifier, the debugger would affect
the timing and hence the bug.
For OTMP I built an ultra-low cost logging package that I use to
monitor the behaviour of the code with a minimal affect on its
performance.
What performance penalty will I expect to pay for this approach?
I would expect it to be quite significant, particularly on
traditional Mac OS. The reason for this is the latency to schedule
the system task time code. This is explained in detail in the
"Justification" section of the documentation that comes with OTMP.
And finally, am I bound to dereference a pointer to an object that
is no longer valid when my system task runs?
The standard OT rules apply. When you call an asynchronous routine,
you must ensure that any output pointers continue to exist until the
asynchronous routine completes. Consider the following example.
err = OTBind(ep, &bindRequest, &bindResult);
The call can dispose of the bindRequest parameter as soon as OTBind
returns. However, the caller must ensure that the bindResult
parameter exists until the T_BINDCOMPLETE event is delivered. It's
the address of this structure that's passed as the cookie to the
notifier. Typically the notifier is responsible for either disposing
of the parameter, or signalling some other code to dispose of it.
If you defer all notifications until system task time, similar rules
apply. Effectively, there are two notifiers. The first is the one
that's called by OT at deferred task time. The second is the routine
that actually runs at system task time. Typically all of the work
that would normally be done in the first is deferred until the
second. This includes disposing of any output parameters.
An even better idea is to allocate the bindResult parameter as a
field in your connection record that's associated with the endpoint.
Thus it continues to exist for the lifetime of the endpoint. It
wastes a little memory but it's much easier to organise.
In a similar vein, you should try to avoid allocating and
deallocating memory on the fast path. While OT's allocator is fast,
it still represents a significant cast.
* * *
Finally, another way to get source level debugging of a notifier is
to do the debugging on Mac OS X. Both GDB and CodeWarrior can handle
source level debugging of 'interrupt time' code on Mac OS X. Of
course, when you bring your code back to traditional Mac OS, it's
likely that you will encounter some gnarly porting bugs, typically
race conditions as I've mentioned above.
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.