🚀 go-pugleaf

If calls on resource-allocation functions were made through a
library of new accessing routines, it seems to me that automatic
task-termination might be possible.  The 'rules' of the new routines
would be that petitioners must SIMULTANEOUSLY specify not only the
resources that they wish allocated (memory, I/O ports, libraries, etc),
but the address of a 'cleanup' function as well.  The new routine would
append the cleanup information to a linked list, and then pass off to
the appropriate allocator.

Freeing the task's resources should then simply be a matter of
traversing the list backwards, calling the indicated functions
to reverse whatever allocation/opening/creating/segloading/locking/etc
had been done.  The list nodes would probably have to also contain
appropriate arguments.

Since most allocatable things I can think of are ultimately represented
by address pointers, it should be easy to search the list for a specific
resource, and excise its cleanup node.  This would allow an application
to release a resource out-of-sequence, in such a way that it doesn't
get re-released by an automatic task kill.


Hopefully, the newsgroup's experts can explain why this tracking
scheme is unworkable.  Such explanations are easily more educational
than double their weight in manuals, and I can obviously stand a
lot more education!


Rudimentally,

Brian Rhodefer    ..!tektronix!tekig5!brianr