🚀 go-pugleaf

In article <1574@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:

[ much good stuff deleted ]

>In the specific case of the serial-to-disk accessory, I recommend
>allocating a buffer when you start up, filling that buffer at interrupt
>level or with AES events (esp.  if you will never run any non-AES
>programs).  Then, when the buffer is full, you can open a file, write
>the buffer to it (even append the buffer to it) and close the file, all
>at once, without ever giving the mainline a chance to terminate. 
>

Since we are getting down to details, I thought I'd point out that
allocating memory and opening files in the desk accessory can fail
if GEMDOS isn't in a state ready to deal with it.   For example,
if the GEMDOS program running at the time AES schedules the ACC
has already opened too many files for GEMDOS to handle, or if
it has already grabed all of memory, the accessory isn't going
to be able to open/allocate successfully.  That's part of the
problem where the accessory really doesn't have any idea what
the state of the rest of world is (not without cheating at least).
There are a lot of other potential "GEMDOS state" related things
to consider, like changing directories or wiping out the Fsfirst()
(DTA) buffer.  This could really screw up the "real" GEMDOS process
if the ACC doesn't restore things.

Do I hear you saying "Nah, that probably won't ever happen?"

-- 
David Beckemeyer (david@bdt.UUCP)	| "Adios amigos.  And, as they say when 
Beckemeyer Development Tools		| the boys are scratching the bad ones,
478 Santa Clara Ave. Oakland, CA 94610	| 'Stay a long time, Cowboy!'"
UUCP: {uunet,ucbvax}!unisoft!bdt!david	|                  - Jo Mora