Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!tektronix!tekig!tekig4!brianr
From: brianr@tekig4.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: A proposed solution to the resource tracking problem
Message-ID: <1930@tekig4.TEK.COM>
Date: Wed, 16-Sep-87 19:15:31 EDT
Article-I.D.: tekig4.1930
Posted: Wed Sep 16 19:15:31 1987
Date-Received: Sat, 19-Sep-87 07:14:51 EDT
References: <636@sugar.UUCP> <81@ur-tut.UUCP>
Reply-To: brianr@tekig4.UUCP (Brian Rhodefer)
Organization: Tektronix, Inc., Beaverton, OR.
Lines: 38
Keywords: Resource tracking

This naive suggestion is only just barely making it past
my foot-in-mouth-avoidance inhibitions, so I'll keep it
short:

Is there any merit in the notion of maintaining a linked
list of pointers to subroutines which do "cleanup" type
activities such as device/window/message port closing,
as well as memory deallocation?  Sort of an extension to
the Memlist idea.

"Killing" a task would then involve scanning its "cleanup"
list in reverse order of creation.

The cleanup list is built by substitutes for the normal CreateXXXX
functions; the substitutes call their forebears, and then add the
appropriate information to the task's current cleanup list.  The
cleanup vector in some (maybe most) cases will be implicit (e.g.,
NewOpenWindow automatically links a pointer to a CloseWindow call),
but some might have to be supplied explicitly.

I suppose the list would have to be more than mere pointers to
existing subroutines;  it needs to include the appropriate
parameters for those subroutines; probably faked-up stack frame images.
This could tie up a fair ammount of memory in its own right, but would
save a lot of code that's currently being generated in each of a zillion
applications.

The list-unwinding program would be included in the code currently
pointed to by a Task's exit vector (I haven't my manuals handy,
but I remember there being one).

I haven't figured out how to deal with unreturned messages in this scheme,
but there might be a way, mightn't there?


Staring wistfully in through real programmers' windows,

Brian Rhodefer