Re: [Squeak-VMdev] squeakVM session ID instead of each plugin handling it?

[David T. L. <le...@ma...>]

On Mon, Sep 09, 2002 at 05:37:54PM -0700, Tim Rowledge wrote:
> Some time ago Dave Lewis worked up changes to replace the multiplicity
> of session ID handling functions found in several plugins (file,
> asynchfile, socket, etc) with a single client in the core vm. The code
> is out of date right now (at least the version I have sitting around)
> but the changes are very simple.

A description of the changes, from the preamble of the change set:

Adds a #getThisSession method to the Interpreter, and makes it
accessible to the interpreter proxy for plugins. Increments the
VM_PROXY_MINOR version number to 5. Modifies FilePlugin and its
support code to use the new mechanism.

The session identifier is a 32 bit integer which is used in
SQFile data structures. It is also a field in the SQSocket data
structure, although this is currently unused (at least in the
unix implementation of the socket code). The session identifier
is also potentially useful for identifying distributed squeak
images, and for handling any external resource whose Squeak
representation may become invalid after restarting the image.

This change set moves the session identifier code from the
FilePlugin support code into the Interpreter, and makes it
available to any plugin by means of the interpreter proxy.
Any plugin which needs to obtain the session identifier may
now do so with 'intepreterProxy getThisSession' (in Smalltalk)
or 'interpreterProxy->getThisSession()' (in a hand-coded C plugin
or support code).

The function which initializes the session identifier is defined
as a macro in sq.h, so that it can be easily replaced by a
function in support code if it needs to be improved.
 
> Question - given that it requires a rev in the sqVirtualMachine
> structure stuff, is it actually worth doing? Personally I'd say yes and
> include it in the VI4 stuff since that is going to require a total
> step-function update. It removes some code from several places and
> replaces it with code in one place, which usually saves some problem
> later.

If the answer turns out to be "yes", I'll be happy to bring it up to date.

Dave