Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!unisoft!gethen!bdt!david
From: david@bdt.UUCP (David Beckemeyer)
Newsgroups: comp.sys.atari.st
Subject: Re: <Control> C and autostarting GEM programs
Message-ID: <167@bdt.UUCP>
Date: 3 Mar 88 21:39:35 GMT
References: <217@piring.cwi.nl> <999@atari.UUCP>
Reply-To: david@bdt.UUCP (David Beckemeyer)
Organization: Beckemeyer Development Tools, Oakland, CA
Lines: 51


Since this discussion hasn't ended yet, I thought I'd bring up a few
gotcha's regarding writing your own ^C and bomb handlers.

GEMDOS calls the Pterm handler with all files open, and it could
happen at any instant in the code.  Consider a recursive File Tree
scanner that uses Fsetdta() and Fsfirst/Fsnext:


scan(pattern, mask)
char *patter;
int mask;
{
	DMABUFFER dbuf, *olddma;

	/* remember callers DTA buffer */
	olddma = Fgetdta();
	/* Set DTA buffer for this scan */
	Fsetdma(dbuf);
	if (Fsfirst(pattern, mask) == 0) {
		do {
			/* see if found a directory */
			if (isdirectory(dbuf))
				scan(pattern, mask);
			else
				/* process file */
		} while (Fsnext() == 0);
	}
	/* reset DTA */
	Fsetdta(olddma);
}

If a bomb or ^C occurs at recursion level N, the dta pointer points
to memory on the stack (the auto dbuf variable). Clearly there are
potential problems here.  What happens to the stack?  How can the
handler fix-up the stack?  A long-jump?  But then what happens in
the above case where now the DTA points to a place that will be used
again for new stack space.

Open files also remain open when the Pterm is called, so these must
also be cleaned up.

My point is: don't be mislead into thinking that a Pterm handler is
nothing more than a simple longjump.
	
	
	
-- 
David Beckemeyer			| "To understand ranch lingo all yuh
Beckemeyer Development Tools		| have to do is to know in advance what
478 Santa Clara Ave, Oakland, CA 94610	| the other feller means an' then pay
UUCP: ...!ihnp4!hoptoad!bdt!david 	| no attention to what he says"