"Raab, Andreas" wrote:
> 
> Stephan,
> 
> [Re: Feedback]
> > I think I have to advertise my current VM changes again, because there
> > was no feedback till now, but I'm very convinced that these changes
> > should be in the next VM, if they work at other platforms, too!
> 
> I was keeping quiet because there were so many change sets coming in so fast
> that I wanted to see what will come out of it once the dust settles.

Good idea! ;-)

> Since
> you're reposting the changes now I figure this is the time ;-)
> 
> [Re: Named primitive failures]
> > *Currently* the module variant is much slower, because loading of the
> > (not existent) module will be tried again and again...
> >
> > but the attached changeset called
> >         'VM_cachingMissingModules.2.cs.gz'
> > *solves* this problem!
> 
> I liked the first approach (having the missing modules somewhere accessible)
> more than the current.

It is correct that it was nice to see the missing modules in ST. But on
the other hand this kind of caching (by a growing array) is
- slower and
- more complicated.
Especially there is a problem if there are many missing modules (because
the searched list of module names becomes longer and longer). With the
current implementation it is really fast!

BTW: What happens with stderr at other platforms? Under Linux it is nice
and sufficient to see which modules are missing...

> While the current approach has it's advantages (in
> particular if there is a function missing in a module) I would very much
> like the idea of having a way to attempt reloading a module if that hasn't
> been found before.

I have to apologize that I have forgotten to remove the comments
	"Future developments: changing thisSession id by a user prim to
force    
	               reloading of external functions..."
	"	self var: #thisSession declareC: 'static int thisSession = 0'."
from Interpreter>>primitiveExternalCall. I have already made these
'future developments'.

So it is possible to attempt reloading a module if that hasn't been
found before by evaluating
	Smalltalk setNewSessionID
(without param). This - indirectly - invalidates all external function
pointers and leads to a new call of
	 ioLoadExternalFunctionOfLengthFromModuleOfLength()
for every used function, which itself loads each module if it hasn't
been loaded (and cached there in a list) before.
Because of this caching of the modules in sqUnixExternalPrims.c it is
not so bad regarding time that all function pointers will be invalidated
by a newSessionID (just like a restart of Squeak).

> Note that this is semantically different from a missing
> function in a module - if the entire module isn't there it's possible to
> find it later

by setting a new session id,

> but a missing function will never be found in the same
> (already loaded) module.

Cached as '0' function pointer with current sessionID.

> 
> [Re: Unloading modules]
> > Another very interesting new feature: Reloading modules without
> > restarting Squeak!
> > Reloading is necessary after recompiling a module and should work both
> > with Plugins and FFI's...
> 
> I have backed away from this with in the original pluggable primitives. The
> reason is that there are systems (do I need to say that one of those begins
> with 'W' and ends with '95'?! but be assured that there are others as well)
> where unloading of modules is an insecure operation. E.g., you *can* unload
> Kernel32.dll on Win95 (at least you still could the last time I tried it)
> and this would be the last thing you ever do...

Ok, but there are many ways to crash Windows95/98 I think...

> 
> [Note: If there is general agreement that we want to have an unload
> primitive I'd be willing to work on it.

There was a posting where someone has wished these functionality...
I think at the current status of Squeak it is nice for developers, but
not necessary for end users.

> There are ways of making sure you
> *don't* unload kernel32.dll accidentally - they're just messy]
> 

> Here are a couple of notes on the session ID:
> * I think that a session id should be set from within the #unload primitive.
> It's trivial to do and prevents an eventual process switch (e.g., from
> within an interrupt).

I was not sure what is the best way to do these things.

I've decided to realize as much as possible in Squeak and to keep the VM
and support file changes as small as possible:
- ST is easy to change later without recompiling the VM,
- minimal use of prim numbers.

But it is a proposal and discussions often lead to better solutions as
swimming only in the own juice...

> * There is the possible danger of a collision between the old and the new
> session ID.

I don't think so: In the *old* implementation there it was possible to
incidentally reuse a session id of an earlier session (see old
implementation of Interpreter>>primitiveExternalCall).
According the *new* implementation the sessionID will be incremented at
every resuming of Squeak modulo from '1' to 'SmallInteger maxVal': this
should be enough for a while, also with extensively reloading of
modules.

> How about finding some sort of a combination of a global session
> ID (which is constant for the entire Squeak session) and a local session ID
> (which starts at zero when the image comes up and counts up to where you
> want).

Would be possible, but it isn't necessary IMHO. Keep it simple!

In the normal case of an end user the sessionID isn't of any interest
and will just be automatically incremented '1' by '1' for every global
session: the modules are installed once and that's it. And to reset all
stored session IDs for e.g. a new Squeak release someone could write a
corresponding ST method if he/she wants to.

> * I am not sure if it's necessary to expose the session ID at all to the ST
> level. It might be a good idea to hide it completely since messing around
> with the session ID could have fatal results.

This is true. The corresponding methods should be made private or
'forDevelopersOnly' or similar...
No end user should change these IDs!
But I think this is no reason to leave it inaccessible at all: There are
some other very critical parts in ST, too, which no end user should
manipulate...

> 
> [Re: Porting issues]
> > I *need* feedback, because I'm not able to test these changes at other
> > platforms and want to ensure platform compatibility *before* posting it
> > as [VM][ENH].
> 
> The basics of what you've done in the support code are trivial to do on
> Windows (and I believe on Mac as well). There may be tricky parts (see the
> example of kernel32.dll) but they can be handled given some time (I would
> probably just do the trivial version and wait until somebody on the list
> does the real thing ;-)

This sounds good to me :-))

> 
>   Andreas

Stephan
-- 
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