cc100aa@prism.gatech.EDU (Ray Spalding) (06/24/89)
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.
--
Ray Spalding
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!cc100aa
Internet: cc100aa@prism.gatech.edumcli@joker.optics.rochester.edu (Maurice Ling) (06/27/89)
In article <882@hydra.gatech.EDU> cc100aa@prism.gatech.EDU (Ray Spalding) writes: >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. Could you post the source code that you wrote? Just posting what the problem is is not enough!!!! Why don't you use the ROM driver? Maurice ************************************************************************ * * * Optics... The wave of the future ** ** ** * * * * * * * * * * BITNET : MCLI_SS@UORDBV, MCLISS@UORVM * * * * * UUCP : ...rochester!uhura!mcli ** ** ** * * Internet: mcli@uhura.cc.rochester.edu *** *** *** * * ***** ***** ***** * ************************************************************************ ************************************************************************ * * * Optics... The wave of the future ** ** ** *
tim@hoptoad.uucp (Tim Maroney) (06/28/89)
In article <882@hydra.gatech.EDU> cc100aa@prism.gatech.EDU (Ray Spalding) writes: >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. In article <2379@ur-cc.UUCP> mcli@joker.optics.rochester.edu (Maurice Ling) writes: >Could you post the source code that you wrote? Just posting what the >problem is is not enough!!!! Why don't you use the ROM driver? Sure it's enough. The problem is simple and common to all serial driver software -- if the serial driver is open, RAMSDOpen will hang. I have seen the same thing. I believe the way around this is to make a status control call to the driver. If it succeeds, then the driver is open and you better not call RAMSDOpen. If it fails with a bad unit error, then the driver is not now open and you can go ahead and open it. I haven't tried this, but it should work. It probably suffices to check either the input or the output driver for the port you want, but true paranoia would demand checking both. And as for why not to use the ROM driver -- try reading Inside Mac IV-225. You are supposed to always use RAMSDClose and RAMSDOpen now, and have been for about three years. Finally, Maurice, please fix your gol-danged signature! Isn't it long enough without seven lines of extra repeated crud at the end? How many times do we have to see this thing? -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Postal: 424 Tehama, SF CA 94103; Phone: (415) 495-2934 "Jesus died for somebody's sins, but not mine." -- Patti Smith
cc100aa@prism.gatech.EDU (Ray Spalding) (07/01/89)
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