Dear VM-Hackers!

"David T. Lewis" wrote:
> 
> On Sun, Jul 16, 2000 at 09:09:10AM -0700, Tim Rowledge wrote:
> > In message <20000716011858.A13433 at conch.msen.com> you wrote:
> >
> > > "thisSession" is a global declared in sqFilePrims.c. I suspect that the
> > > recent plugin-ization of the VM has bitten me here. I'll check it out on
> > > the latest from SourceForge. Thanks.
> > IIRC (it's a long time ago for me...) we removed the global thisSession
> > idea for the pluginization. Take a look in some ofthe plugin files and
> > you'll probably find what we did- which I think was just localizing the
> > idea into each plugin.
> >
> 
> Yes, that's right. thisSession is used only in sqFilePrims.c. It's
> a field in the SQFile data structure, and is used in the sqFileValid()
> function to prevent core dumps which would arise from trying to
> access a file pointer from a previous Squeak session. I use it in
> the UnixOSProcessAccessor module, which directly manipulates SQFile
> data structures (for example, when creating a Unix pipe and making
> it look like a FileStream to Squeak).
> 
> A startup/shutdown mechanism on the Squeak side might make this
> validity check unnecessary, so the thisSession identifier could
> be eliminated entirely. I have not checked into this, but it certainly
> seems possible to come up with something.
> 
> On Sun, Jul 16, 2000 at 06:09:29PM +0200, Stephan Rudlof wrote:
> >
> > IMO thisSession shouldn't be declared in sqFilePrims.c, because
> > obviously it isn't file specific.
> > I don't like the idea to move it to sqXWindow.c though, because this is
> > Unix specific.
> >
> > I'd rather vote for moving it into a platform independent file.
> >
> >  The question for me is, if to move it to
> > - sqVirtualMachine.c, or
> > - back into the interpreter, where it was before.
> >
> > The advantages of the latter are, that we could make it accessible by ST
> > as standard and ensure that we always generate a new one (at least in
> > 2.9alpha).
> >
> 
> It depends on whether the concept of a "session hash" is of some
> general use.

I think so.

> For example, it might be needed to support unique
> identifiers for distributed Squeaks.

Good point!

> If so, thisSession
> (or something like it) should go into the core VM where any
> plugin could get at it. On the other hand, if it's really used
> only by the sqFile support code,

It could also be used by other modules, which were implemented before
the modularization.

> then I think we should leave
> it nicely modularized, and I will need to think up some way to
> make my UnixOSProcessAccessor module work without it.

I think your use is the second one *known* - and there is a potentially
other one mentioned by you below - and the overhead for moving the
sessionID back into the interpreter is minimal.

I think it makes sense to give all the possibility to use a sessionID
however they like. There are just some issues (already solved by earlier
[uses|code variants] in the VM) if it is stored in the image and has to
be initialized at startup.

So for 2.8 I would say it should stay in sqVirtualMachine.c without
changing the interpreter and for 2.9alpha we should go the more general
path.

Stephan

> 
> Dave
> 
> p.s. The SQSocket data structure contains a sessionID field which
> was obviously intended to be used like the sessionID field in
> the SQFile data structure. It is unused in the Unix support code.

-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3