• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
[OpenTransport] debugging my NotifyProc callback
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[OpenTransport] debugging my NotifyProc callback


  • Subject: [OpenTransport] debugging my NotifyProc callback
  • From: "Thomas E. Knowlton, Jr." <email@hidden>
  • Date: Fri, 5 Dec 2003 14:02:06 -0700

I'm having a bear of a time debugging my NotifyProc; setting breakpoints with CodeWarrior frequently results in freezing the machine, causing me to have to cycle power. Macsbug is somewhat more reliable, but still sometimes freezes the machine, and what's more, it's a bear to get usable debugging info from Macsbug, as I am not much of a PPC assembly programmer.

So, I got to thinking, maybe deferring the NotifyProc handling to system task time will make debugging at least possible.

I created a NotifyProc that looks something like this:

pascal void NotifyProc(void *context, OTEventCode code, OTResult result, void *cookie)
{
// dequeue a "NotifierContext" from a big 'ol grundle of such objects that were pre-allocated.
// call NotifierContext's ScheduleDeferredNotify() method.
}

and that ScheduleDeferredNotify is defined as:

void ScheduleDeferredNotify(void *theContext, OTEventCode theCode, OTResult theResult, void* theCookie)
{
if (! OTAtomicSetBit(&mIsScheduled, 0))
{
mContext =theContext;
mCode = theCode;
mResult = theResult;
mCookie = theCookie;
OTScheduleSystemTask(mTask); // previously created in the constructor for "this"
}
else { ... } // indicate a failure to manage the free-list properly.
}

The "NotifierContext" mTask proc simply calls out to a function having the same signature as the original NotifyProc.

In addition to the debugging benefits I imagine I will gain, I thought this would be a great way of gaining access to Toolbox code, etc., from my "secondary" NotifyProc. Then, I realized that I don't know whether the cookie will remain valid. For example, in the case of a T_BINDCOMPLETE, the cookie is a pointer to a TBind. Will that TBind remain valid when I return from the "primary" NotifyProc? How does OpenTransport decide when to clean up the objects referred-to by the cookies passed to the notifiers? I'm wondering whether my approach that blindly defers, without regard to the OTEventCode, must eventually be unsafe.

Can anyone comment on this approach? Got a better idea for gaining reliable high-level debugging for the NotifyProc? What performance penalty will I expect to pay for this approach? And finally, am I bound to dereference a pointer to an object that is no longer valid when my system task runs?

Thanks in advance,
--
Tk!
_______________________________________________
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.

  • Follow-Ups:
    • Re: [OpenTransport] debugging my NotifyProc callback
      • From: Quinn <email@hidden>
  • Prev by Date: Re: NDRV sockets and Protocol Match error
  • Next by Date: Re: NDRV sockets and Protocol Match error
  • Previous by thread: Re: NDRV sockets and Protocol Match error
  • Next by thread: Re: [OpenTransport] debugging my NotifyProc callback
  • Index(es):
    • Date
    • Thread