🚀 go-pugleaf

In article <1158@gmdzi.UUCP> kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes:
> What about an open file? Is the file already closed when the AC_CLOSE
> comes or have I to close it? And when may I reopen it?

Unfortunately, there is a lot of confusion about how the various parts
of the OS interact, especially with respect to desk accessories.

One crucial thing to remember is that desk accessories are meant to
be like the Control Panel or a calculator or something -- you open
them, use them, and close them.  Desk accessories which do things in
"background" are an extension to this concept, and much trickier.

For one thing, a desk accessory is not a separate GEMDOS process, though
it is a separate AES application (it has a separate AP_ID (doesn't
it?)).  The things which AES handles, therefore, are pretty well dealt
with when it comes to desk accessories.  But GEMDOS simply doesn't know
the difference between the mainline application and the accessory. 

There is [conceptually, at least] a sentence in the GEMDOS documentation
which says, "All of a process' open files are closed when the process
terminates, and all the memory it owns is freed." What it doesn't say is
that files opened by a desk accessory (and memory allocated by it) are
considered owned by the mainline process, so when the mainline process
terminates, they are closed (freed). 

Therefore: DESK ACCESSORIES SHOULD NOT OPEN FILES OR ALLOCATE MEMORY
WHEN THERE IS ANY CHANCE OF THE MAINLINE PROCESS TERMINATING.

The Desktop never terminates, and it's the mainline process when your
desk accessory starts up, so it is safe to open files and allocate
memory when you start up, BEFORE YOU MAKE ANY AES CALLS (including
registering yourself in the Desk menu). 

However, not all processes which run are AES processes, so you can't
count on getting AC_CLOSE before process termination.

What *is* safe for the event-driven part of your accessory, however, is
to open a file and/or allocate memory, do some work, then close/free
what you opened/allocated, without making any intervening AES calls.  If
you don't make any AES calls, you'll never stop running, and the
mainline never gets a chance to terminate.  This is not safe for any
interrupt-driven part of an accessory; that's a totally different kettle
of fish. 

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. 

I hope this clears up some of the remaining confusion about desk
accessories. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt