[VM][OSPP] bug alert: OSProcess breaks with recent SVN source tree

Problem:
OSProcess fails when running on a VM built from the latest source tree.

Triggering event:
Change to SQFile struct in FilePlugin.h to resolve an alignment problem.

Action required (for Ian and/or me):
Before building a Unix VM with OSPP for general distribution, change
UnixOSProcessPlugin class>>concreteClass to remove a kludge I put in a few
years ago. The de-kludged method UnixOSProcessPlugin class>>concreteClass is:

  concreteClass
      self hasInterpreterGetThisSession
         ifTrue:
            ["Preferred technique, requires modified Interpreter"
            ^ UnixOSProcessPluginInterpreterGetThisSession].
      self hasThisSessionAccessorInFilePlugin
         ifTrue:
            ["Not a bad way to do it if VMMaker changes have been loaded"
            ^ UnixOSProcessPluginDynamicThisSession].
      ^ UnixOSProcessPluginStaticThisSession   "The old way to do it"

(well, I suppose it's a bit of a stretch to call this "de-kludged" ;)

Background:
In OSPP, I have several possible ways of obtaining the SQFile->sessionID
(this value is required when creating an OSPipe, which is modeled to look
like a pair of connected FileStreams, or when creating the file streams for
stdin, stdout, stderr). One way that works with the current sources is to
get it from the FilePlugin. If I remember right, this caused a problem in
that it required FilePlugin to be built internally, or something like that
(I don't remember exactly what the concern was). In any case, I decided to
punt, and I have OSPP set up to deliberately fail its primitiveGetSession,
and let OSProcess figure it out by pulling the sessionID out of some existing
FileStream instance (e.g. the changes file). This removed the dependency
between FilePlugin and OSPP, but will fail if the SQFile structure changes.

This worked fine for a long time, but now the SQFile struct has changed
(sessionID is in a different slot to fix an alignment problem), and in any
case it is not going to work with a 64 bit image. Thus I now need to go back
to obtaining the sessionID from a primitive call.

This will of course require an update to OSPP on SqueakMap, but I'm just now
starting to look at the 64bit issues (not much so far :)), so I am not going
to put out any OSPP releases right away unless there is an immediate need.

Note: The right thing to do is to have a global sessionID that can be used
by any plugin that requires it, which currently is FilePlugin, SocketPlugin,
and OSProcessPlugin. It probably is also a good idea to make the value
available through a primitive, similar to the way we obtain system time
or timezone offset. That would make sessionID available to the image for
purposes of e.g. identifying unique Squeak sessions on the internet.

Dave

In message <[hidden email]>
          "David T. Lewis" <[hidden email]> wrote:

> Note: The right thing to do is to have a global sessionID that can be used
> by any plugin that requires it, which currently is FilePlugin, SocketPlugin,
> and OSProcessPlugin. It probably is also a good idea to make the value
> available through a primitive, similar to the way we obtain system time
> or timezone offset. That would make sessionID available to the image for
> purposes of e.g. identifying unique Squeak sessions on the internet.
I agree strongly. I even have your old code for this sitting around. The issue
is that a plugin expecting the vm to supply session id would have to run with a
vm able to so do. It seems some people mix releases and might get upset by
this. Personally I say to hell with them. Others might disagree.

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Terminal glare:  A look that kills...

On Mon, Jun 13, 2005 at 04:49:12PM -0700, Tim Rowledge wrote:
In principle, this is very important (maintaining backward compatibility
such that an external plugin will work with a VM that might not be at
the same version level). In practice, it is unlikely that a Squeak user
would mix a newer FilePlugin with and older VM, since most folks obtain
and install both at the same time.

A conservative approach would be to introduce the changes into the VM,
then update the FilePlugin, SocketPlugin, and OSPP about 12 months
later. But really I don't think it's necessary to be so conservative
in this case. It's not as though we're burning the disk packs.

Dave

> I agree strongly. I even have your old code for this sitting around. The issue
> is that a plugin expecting the vm to supply session id would have to run with a
> vm able to so do. It seems some people mix releases and might get upset by
> this. Personally I say to hell with them. Others might disagree.

Backwards compatibility is important but I think we can dodge this one
easily. Because the worst thing that may happen is that you use a
FilePlugin which does not use the VM's session ID but its own one (which
may not be nice but is certainly not fatal). The other way around (a
newer file plugin working with an old VM) is easily prevented by
increasing the vm proxy's minor version which we need to do anyway if we
extend the interface. In short, I don't see an issue with backwards
compatibility - old versions will continue to function with new VMs and
that new plugins may not function with old VMs is a fact of life.

Cheers,
   - Andreas

In message <[hidden email]>
          Andreas Raab <[hidden email]> wrote:

> > I agree strongly. I even have your old code for this sitting around. The
issue
> > is that a plugin expecting the vm to supply session id would have to run
with a
> > vm able to so do. It seems some people mix releases and might get upset by
> > this. Personally I say to hell with them. Others might disagree.
>
> Backwards compatibility is important but I think we can dodge this one
> easily.
Good point. We're already opening a new VM_PROXY_MINOR level for
fetchLong32ofObject so adding the sessionID doobry will be no problem. At last,
an excuse to add this small but pleasing cleanup!


tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Strange OpCodes: MBR: Move Bits Randomly

(Resent - got the wrong mail list the first time)

OK, getThisSessionID is now in VMMaker. It requires a change in the
sqVirtualMachine.[ch] files which makes them break with older code so I'll hold
off for a short while before commiting them.

To benefit from the change, platformPeepul will need to make small alterations
to any platform plugin code( so far file plugin & socket plugin are likely
suspects) that uses the idea of a session id.


tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Useful random insult:- Life by Norman Rockwell, but screenplay by Stephen King.

A new VMMaker with the core-provided getThisSessionID  is now available at
http://www.rowledge.org/tim/squeak/SqFiles/packages/VMMaker/VMMaker-tpr.37.mcz

I also svn-committed the sqVirtualMachine.[ch] changes required to add the
getThisSessionID function to the proxy, along with changes to the
FilePlugin/sqFilePluginBasicPrims.c to use the new doobry. Of less interest is
the new RISC OS file & socket plugin files altered to use it; though the fact
that it all compiled and is running ok may encourage you.

I also finally removed the old function dispatch macros from sq.h - Bernd
spotted that we had left them lying around like old beer cans.

This is one of those double-ended updates needing both the new SVN files and
the new VMMaker package.

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
A)bort, R)etry, I)nfluence with large hammer.

Thanks Tim! This is great!

Cheers,
   - Andreas

Tim Rowledge wrote:

In message <[hidden email]>
          Andreas Raab <[hidden email]> wrote:

> Thanks Tim! This is great!

Thank you, kind sir. Nice to be appreciated.

The next set of changes I'd like to make involve dropping a lot of ancient
stuff - obsolete Numbered/Named primitives, the old io polling junk etc.
Obvioulsy this would remove support for older images but since I see it as a
temporary precursor to finally doing the compiled method changes this doesn't
seem like a problem. With CM changes, drop old crap and 64 bit support I really
think it makes sense to drop backward compat limitations. It is, after all, ten
years now.  Really old images can still run on really old VMs. If anyone
really, truly cares, they could make a simulator version to support old images
enough to clone replacements.

tim
--
Tim Rowledge, [hidden email], http://www.rowledge.org/tim
Useful random insult:- Overdue for reincarnation.