Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun!imagen!atari!kbad
From: kbad@atari.UUCP (Ken Badertscher)
Newsgroups: comp.sys.atari.st
Subject: Re: Communicating with Desk Accessories
Summary: DA's only need to free things they allocate during applications.
Message-ID: <1568@atari.UUCP>
Date: 16 Jun 89 20:00:29 GMT
References: <8660@chinet.chi.il.us> <507@electro.UUCP> <1553@atari.UUCP> <510@electro.UUCP>
Reply-To: kbad@atari.UUCP (Ken Badertscher)
Organization: Atari Corp., Sunnyvale, CA
Lines: 29


Desk accessories eating memory on resolution changes is a mystery to
me.  I haven't witnessed the phenomenon myself, because I've never
looked (I don't switch res very often).  I have no idea why some DA's
exhibit this behavior and others don't.

To cover other questions brought up recently, though -

Because a desk accessory is *not* a process, it does not own memory it
allocates or files it opens.  GEMDOS doesn't know about DA's, so when a
DA allocates memory or opens files, GEMDOS assigns ownership to the DA's
parent process.  What this means is that if a DA allocates memory while
an application is running, that memory will be freed out from under the
DA when the application finishes.

If a desk accessory needs memory that won't be treated like this, it
must allocate that memory before it goes into its main event_multi loop.
That way, the allocated memory belongs to the AES shell, which is
actually the pseudo-process to which all DA's belong.  Memory allocated
in this way won't be freed until a resolution change or reboot.

The only thing a DA needs to free on an AC_CLOSE message is memory it
has allocated or files it has opened during the main event_multi loop,
because it is possible that such memory/files actually belong (as far as
GEMDOS is concerned) to the application that is about to terminate.
-- 
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>