🚀 go-pugleaf

Following up on Rob Peck's ideas on resource tracking, here's some thoughts I
had the other day while walking to work (its a 25 minute walk over a big,
windy bridge).

Extend all of the standard system structures (Window, Screen, Gadget, Menu,
Message, Port, etc.) with a field to contain a unique identifier. The
identifier will not repeat until after a reboot, but also contains the
task number (so it might need to be 64 bits). This identifier is placed in
all of the structures when the system creates the structures. (Note: the
structures should be self validating, that is, given a pointer to one, the
system can very quickly verify that it is a valid pointer to such a
structure. One way to be almost certain is to have yet another added 32 bit
field which contains some fast-to-compute, but difficult to fake without
knowing what it is, function of the address of the structure. When receiving
the address of such a structure, the system can do a quick check and then
be almost sure that it is valid.) We now add a new, required, entry point
to all of the libraries (exec doesn't really need one since he is the one
that is going to do the magic). This entry point is called by exec, with the
unique identifier of a current task, when that task is going away, either by
committing suicide or by being killed by someone else. The library should
then free up all resources that the task has allocated within the library.
User-provided libraries have the same facility available to them. It will
probably be helpful to have a priority associated with a library, which
governs the order in which their "taskIsDying" functions are called. This
would, for example, allow Intuition to close down all Windows and Screens,
which would result in the ViewPort, Rasters, etc. going away, before calling
the function for the graphics library, which would also want to remove those
items. Some of the libraries wouldn't even need any extra data structures
to do the required tracking - e.g. Intuition always has all Windows and
Screens nicely tied together in lists. Some structures, such as messages,
may not "belong" to the dying task when it dies. They should stick around, and
only be freed when the current owner attempts to send them elsewhere. A new
error result would indicate "recipient has died". This is probably easier
than trying to rip all of the messages away from their current owners.

Another note: I would hope that if/when we switch to an Amiga system that
supports MMU and/or does resource tracking and/or has no BCPL stuff, that
all three happen at once. That way we only need to go through a totally
incompatible system once. I wouldn't expect to see such a system for a couple
of years. Thinking about how to do some hooks to properly integrate the
graphics, sound, input, etc. aspects of the Amiga with a hosted UNIX system
might be productive at that point, also.

-- 
Chris Gray		Myrias Research, Edmonton	+1 403 428 1616
	{uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg