kloppen@gmdzi.UUCP (Jelske Kloppenburg) (06/19/89)
If a Desk Accessory has an open window (in my case looking down RS232)
and AES sends an AC_CLOSE, the window is closed. My DA must not call
a window close, it would close another window of the DESKTOP.
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?
I have an otherwise unused 520ST connected as printer at our X25 switch.
(ca. 150.000 Bytes/hour)
A Desk Accessory writes all data from RS232 to disk. Starting a new
file every hour. With an editor I open and close the older files.
That works fine.
According to what I read here, I fear that with TOS 1.4 my file will be
really closed. So I want to know what to do. I could leave the 520ST
as it is. But what is the correct method?
kloppenburg@kmx.gmd.dbp.de
UUCP: kloppen@gmdziapratt@atari.UUCP (Allan Pratt) (06/20/89)
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
kloppen@gmdzi.UUCP (Jelske Kloppenburg) (06/20/89)
In article <1158@gmdzi.UUCP>, kloppen@gmdzi.UUCP (Jelske Kloppenburg) writes: > ... > A Desk Accessory writes all data from RS232 to disk. Starting a new > file every hour. With an editor I open and close the older files. > That works fine. > ... No, it does _not_ work fine. When I terminate the editor, the file open for the Accessory is closed and - shame on me - I didnt test the write on success. That answers part of question one: The Accessory need not close the file. But - is it already closed or will it be closed? And - when may I reopen it? It could even happen, that I write into a file that is just opened by a programm! kloppenburg@kmx.gmd.dbp.de UUCP: kloppen@gmdzi
saj@chinet.chi.il.us (Stephen Jacobs) (06/21/89)
In article <1574@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: [Many wise things, including] > 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. An amusing experiment to try when you're finished using a GEM application and don't mind rebooting is to open the Control Panel, then quit the application with the Control Panel still open. The results may be somewhat variable, depending on the applocation. But for at least one application, on a 1040 ST with original ROM TOS, this causes a normal return to the desktop, with the Control Panel closed, but with the Control Panel's memory of ALL colors set to the desktop background. That means that the next time the Control Panel is openned, the screen goes blank (or bright green, or whatever). Please interpret this note as an observation that abusing desk accessories can cause surprising results, not as criticism of ANYTHING. Steve J.
R_Tim_Coslet@cup.portal.com (06/21/89)
In article: <1574@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >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. [...] >Therefore: DESK ACCESSORIES SHOULD NOT OPEN FILES OR ALLOCATE MEMORY >WHEN THERE IS ANY CHANCE OF THE MAINLINE PROCESS TERMINATING. [...] >However, not all processes which run are AES processes, so you can't >count on getting AC_CLOSE before process termination. [...] >I hope this clears up some of the remaining confusion about desk >accessories. So THAT is why NeoDesk's "Printer Queue" accessory occasionally (but not always) aborts or errors in the middle of printing a file when I exit the program I have been running!!!! R. Tim Coslet Usenet: R_Tim_Coslet@cup.portal.com BIX: r.tim_coslet
david@bdt.UUCP (David Beckemeyer) (06/23/89)
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
apratt@atari.UUCP (Allan Pratt) (06/24/89)
In article <599@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: > 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?" No, you heard someone say, "If you change something, change it back before you let the mainline program run!" The current directory and DTA address can both be saved, changed, and restored before making any AES call (AES can only change tasks during AES calls). And in the serial-to-disk application I was talking about, you should allocate the memory at accessory-start time, and do the open-write-close when you need to, without giving the mainline a chance to terminate during this procedure. By allocating your buffer at the start of the world (mainly, when the Desktop is the current process, because the Desktop never terminates) you know there'll be enough. Yes, there might not be any handles available when you want one, but that *is* unlikely. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
david@bdt.UUCP (David Beckemeyer) (06/27/89)
In article <1583@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >In article <599@bdt.UUCP> david@bdt.UUCP (David Beckemeyer) writes: >> Do I hear you saying "Nah, that probably won't ever happen?" > >No, you heard someone say, "If you change something, change it back >before you let the mainline program run!" Right. That was my main point. You'll notice my posting said: things can go wrong "if the ACC doesn't restore things." I know there are ways to save/restore most things - but the person writing the Desk Accessory has to use them. My point was that the author of the desk accessory must consider all the "context sensitive" things. The DTA and current directory were just two examples - there are many others and not all are related to GEMDOS. I've heard a lot of people say "Nah, ..." and ignore these psuedo concurrency issues and that's why I mentioned it. -- 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