However, note that sqUnixNetwork has its own "thisSession" variable,
called "thisNetSession", which is exactly the same thing but which
duplicates code.  In particular, the algorithm for picking a new session
number is far from obvious.

If a global thisSession were available, the networking code could take
advantage of it.

-Lex



"David T. Lewis" <lewis at mail.msen.com> 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. For example, it might be needed to support unique
> identifiers for distributed Squeaks. 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, 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.
> 
> 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.