On 8 October 2012 13:39, David T. Lewis <[email protected]> wrote:
> I like your idea, but just so this does not get overlooked:
>
> See also [Stack]Interpreter>>getThisSessionID which is used in e.g.
> OSProcessPlugin>>primitiveGetSession for external resource management.
> You could move the primitive into the interpreter if you wanted to make
> it mandatory.
>
> This is the same session identifier that is used in the file and socket
> plugins, so it might have some advantages over using a newly allocated
> object that would not get allocated until after the plugins are already
> initialized. But it does need VM support, so your Object new approach is
> better in that respect.
>
yes, i saw that.
The issue with sessionID, generated by VM, that there is a chance of collision:
globalSessionID := 0.
[globalSessionID = 0]
whileTrue: [globalSessionID := self
cCode: 'time(NULL) + ioMSecs()'
inSmalltalk: [(Random new next
* SmallInteger maxVal) asInteger]].
while 'Object new' can never collide, no matter what happens :)
Also, according to VM sources, this thing is obsolete, or at least not
used as it supposedly should be used,
like in primitive literal:
Interpreter>>primitiveExternalCall
"Call an external primitive. The external primitive methods
contain as first literal an array consisting of:
* The module name (String | Symbol)
* The function name (String | Symbol)
* The session ID (SmallInteger) [OBSOLETE]
* The function index (Integer) in the externalPrimitiveTable
(i don't remember where, i also seen more code, when hacking HydraVM,
with commented
sections of code which dealt with session id, but then turned into NOP).
Another question, why session id was not exposed to language by VM
(your primitive in OSProcess plugin does that, but since plugin is
optional, the question remains the same).
The proposed change is trivial to introduce and use, but what
important, it don't requires altering VM.
Altering VM in order to fix/improve session management, will
immediately bring new issue: how to play nicely when running images
which expect such feature to be present, while users (for no good
reason, of course ;) using old/obsolete VMs to run image.
This is yet another thing which demonstrates that the less code you
put in VM, the less you have to maintain and care less about
compatibility issues.
That's why i think that VM should be stupid, contain no complex logic
and excessive features, only ones
which having good reason to stay there (either no way how to do same
thing in language, or gives a nice performance advantage).
> Dave
--
Best regards,
Igor Stasenko.
