Path: utzoo!mnetor!uunet!lll-winken!lll-tis!oodis01!uplherc!nrc-ut!nrcvax!kvc
From: kvc@nrcvax.UUCP (Kevin Carosso)
Newsgroups: comp.os.vms
Subject: Re: IOSBs on the stack (was Re: 2 C questions)
Message-ID: <1451@nrcvax.UUCP>
Date: 17 Apr 88 05:40:57 GMT
References: <281@cullsj.UUCP> <282@cullsj.UUCP> <4500@blia.BLI.COM>
Reply-To: kvc@minnie.UUCP (Kevin Carosso)
Organization: Network Research Corp.  Oxnard, CA
Lines: 28

In article <4500@blia.BLI.COM> ted@blia.BLI.COM (Ted Marshall) writes:
>In article <282@cullsj.UUCP>, jayz@cullsj.UUCP (Jay Zorzy) writes:
>> Speaking of stacks, here's a common gotcha to watch out for:  If you're 
>> issuing any asynchronous $QIOs (no wait, I/O completion handled by AST
>> routine), make sure to declare your IOSB variables as static.  Otherwise,
>> once the calling routine returns, the stack is reset; an IOSB on the stack
>> may now point to never-never land.
>
>This can bite you even if you use QIOW, IF you have an condition handler
>which unwinds the stack. This bit me.
>    . . .
>Of course, be careful about making things static if the routine is recusive!
>

One way of handling asynch I/O's fairly cleanly is to create a structure
for each I/O you do, consisting of, for example, the buffer for the I/O,
the IOSB, and anything else you might want.  Before you issue your QIO,
allocate your struct and link it into a list.  Your listhead should, of
course, be static.  If you use AST completion on the I/O, you can pass
the address of the per-I/O struct as the AST parameter, making your
buffer, your IOSB, etc. easily accessible to your completion handler.
When you're done with the I/O, you've got a lot of options.  You should
unlink from the list and then deallocate the struct, put it on a free
list for later re-user, or maybe move it to another list to be
post-processed.

        /Kevin Carosso                     kvc@nrc.com
         Network Research Co.              kvc@ymir.bitnet
                                           kvc@nrcvax.uucp