Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!gatech!prism!cc100aa
From: cc100aa@prism.gatech.EDU (Ray Spalding)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Machine hangs if serial drivers not closed
Message-ID: <911@hydra.gatech.EDU>
Date: 30 Jun 89 21:49:50 GMT
References: <882@hydra.gatech.EDU>
Reply-To: cc100aa@prism.gatech.EDU (Ray Spalding)
Organization: Georgia Institute of Technology
Lines: 37

In article <882@hydra.gatech.EDU> I write:
>I'm developing a terminal emulator.  A annoyance is that if my code
>crashes, RAMSDClose doesn't get called and the next RAMSDOpen will
>hang the machine.  From IM-II page 250: "Warning: The RAM Serial Driver
>must be closed with a call to RAMSDClose before your application terminates."
>Does anyone know any way around this?  It sure would speed the development
>process.

Thanks to all who sent me their ideas.  Unfortunately, the situation
turned out to be a little more complex than I thought.  First, I failed
to mention above that a simple FSRead will not return until a character 
is received, so I'm using an asynchronous PBRead that's always 
"in progress".  

Second, RAMSDClose will not return until all I/O is done, so I have to do 
a KillIO before calling RAMSDClose.  KillIO must be done before my 
application exits, otherwise system error 14 usually results (due to the
original parameter block being gone?).  Thus, having a separate utility 
program to call RAMSDClose or calling RAMSDClose upon restarting my 
application won't work.  It also appears my SerSetBuf will hang (due to 
the outstanding I/O?) if I status the driver, find out it was left open, 
and skip a new open.

I also fooled around with the "resumeProc" parameter to InitDialogs.  As
best I was able to determine, the resumeProc doesn't get called if you're
running under MultiFinder (is this considered an incompatibility?), and 
not if you use the 'es' (exit to shell) command from MacsBug.

The only reliable (so far) approach was suggested by dowdy@apple.COM:
patching the ExitToShell A-trap.

Thanks again to all who responded.
-- 
Ray Spalding
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:     ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!cc100aa
Internet: cc100aa@prism.gatech.edu