Re: Handles (was Teraspace memory allocation)

[Ken Sims <ken@xxxxxxxxx>]

Hi Simon -

>Secondly, I think there is a fundamental flaw in your design.  You should
>not be exposing the TS address as the magic cookie cum handle.  Your
>teraspace service program should allocate a chunk of static storage (array,
>user space, user index, whatever) and your new() function should store the
>TS pointer in the array and return a handle that can be used by destroy()
>and any other TS functions to locate the pointer in the static storage.
>That way you don't expose the implementation, you don't have to stuff about
>with pointer conversions, and the handle can be a data type supported by
>all HLLs.
>
>The simplest handle is an integer as an index into the array but it could
>be anything you like and its internal structure can be changed as required
>by the TS service program without breaking existing code.  TS exists only
>for the duration of a job/process thus a handle cannot be stored externally
>to the process and reused in a different process.  You could use the job ID
>as part of the handle to allow you to test and enforce this requirement.

I haven't had the need yet to use dynamic memory allocation, teraspace or
otherwise, but I totally agree with you about using a handle for it.

If used properly, in the right circumstances handles can be the greatest
thing since sliced bread.  They can really give you a handle on keeping
track of things (pun intended).

I use them in one service program for keeping track of the position in a
file.  It's a bunch of key fields and some other control information, all
concatenated together in a data structure.  The programs that use the
service program just see it as a big character field and don't need to know
anything about the contents.

And as you pointed out, I can change the implementation any time just by
changing the service program.  Unless I need to make it bigger, the calling
programs don't need any changes at all, not even recompilation.

Ken
http://www.ke9nr.org/
Opinions expressed are my own and do not necessarily represent the views of
my employer or anyone in their right mind.