Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!apple.com!rmh
From: rmh@apple.com (Rick Holzgrafe)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Safety of using async _Control from ioCompletion?
Message-ID: <7050@goofy.Apple.COM>
Date: 6 Mar 90 18:09:09 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 38
References:<1990Mar5.031521.4774@caen.engin.umich.edu> <10614@hoptoad.uucp>

In article <10614@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes:
> In article <1990Mar5.031521.4774@caen.engin.umich.edu>
> mystone@mondo.engin.umich.edu (Dean Yu) writes:
>>  I know the old litany of not moving memory from a completion routine. 
 What
>>I'm wondering is if it's safe to make an asynchronous _Control call 
from a
>>completion routine.  I was thinking about the AppleTalk drivers 
specifically;
>>if I have all the response and request buffers allocated beforehand, is 
it
>>safe to send an async SendResponse in the completion routine of a 
GetRequest?
> 
> Sure, but just to be safe, use a different parameter block.

Not necessary to use a different parameter block. It is definitely a big 
no-no to use one parameter block for overlapping _Control calls. But when 
your completion routine is called, the original _Control call is 
considered "complete" by AppleTalk: it's through with the parameter block, 
and you can re-use it.

> And at all
> costs avoid the situation where you set up a possibly bottomless
> recursion, where the completion routine for operation A starts
> operation B and the completion routine for operation B starts operation
> A.

Right on! Even short recursions can be dangerous because you can't be sure 
whose stack you're using. We discovered that TimeKeeper has a short stack 
in exactly this fashion.

==========================================================================
Rick Holzgrafe              |    {sun,voder,nsc,mtxinu,dual}!apple!rmh
Software Engineer           | AppleLink HOLZGRAFE1          rmh@apple.com
Apple Computer, Inc.        |  "All opinions expressed are mine, and do
20525 Mariani Ave. MS: 67-B |    not necessarily represent those of my
Cupertino, CA 95014         |        employer, Apple Computer Inc."