On 8 October 2012 13:39, David T. Lewis <lewis@mail.msen.com> 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.