[comp.sys.mac.programmer] Safety of using async _Control from ioCompletion?

mystone@mondo.engin.umich.edu (Dean Yu) (03/05/90)

  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?
Thanks for any thoughts on this subject.

  -- Dean

_______________________________________________________________________________
Dean Yu                            | E-mail:    mystone@caen.engin.umich.edu
Mac Support &                      | Real-mail: Dean Yu
 Self declared License Czar        |            Rm 145 Chrysler Center
University of Michigan             |            2121 Bonnisteel
Computer Aided Engineering Network |            Ann Arbor, MI 48109
     INCLUDE 'Disclaimers.a'       | Phone:     (313) 763-3070
-------------------------------------------------------------------------------

tim@hoptoad.uucp (Tim Maroney) (03/06/90)

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.  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.  You wouldn't think these things would complete immediately and
overflow the stack, and they usually don't, but I have seen some cases
where they do.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"I see little divinity about them or you.  You talk to me of Christianity
 when you are in the act of hanging your enemies.  Was there ever such
 blasphemous nonsense!" - Shaw, "The Devil's Disciple"

jsm@Apple.COM (Jeff Miller) (03/07/90)

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;

Yes, it is safe.  In fact, many device drivers (including AppleTalk I believe)
do this.

Jeff Miller

rmh@apple.com (Rick Holzgrafe) (03/07/90)

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."