On Oct 8, 2012, at 4:12 PM, Igor Stasenko wrote: > 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]].
how can they collide? I do not see it and it should be obvious. I want to learn :) > > 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. Go for it igor. But put a nice comment explaining the Object new > 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. >
