[Vm-dev] Accessing effectiveProcess from a primitive

Eliot Miranda eliot.miranda at gmail.com
Mon Oct 17 21:35:09 UTC 2016

Hi Ben,

On Mon, Oct 17, 2016 at 9:09 AM, Ben Coman <btc at openinworld.com> wrote:

> After falling down a rabbit hole chasing some ideas for waitAcquire
> for the OwnedLock primitives (where I learnt a lot) which came to a
> dead end, and then a few other distractions I'm returnign to complete
> this.  I have a query regarding simulation of the primitives via...
>   Context>>doPrimitive:method:receiver:args:
> The activeProcess is important to the OwnedLock primitives since they
> record which process acquired the lock, however IIUC the active
> process is confused when debugging for which effectiveProcess is
> provided to clarify things.  So in  #doPrimitive:method:receiver:args:
> I am passing the effectiveProcess via the stack and the primitive does...
>   argumentCount > 0
>     ifTrue:
>       [ownedLock := self stackValue: 1.  "rcvr"
>        activeProc := self stackTop]
>     ifFalse:
>        [ownedLock := self stackTop.  "rcvr"
>         activeProc := self activeProcess].
> However I am thinking it would be better from the primitive to
> directly access the effectiveProcess instance variable of Process.

Why?  How would the primitive know to do that?  Also, it implies that every
system from now forward must use the effectiveProcess scheme not only for
for debugging, but adhere to it in normal execution.  Since there is only
one client that needs to pass in the parameter
(#doPrimitive:method:receiver:args:) it makes more sense to me to continue
passing in the parameter explicitly.

> However Squeak 5.1 has ivars...
>   Link subclass: #Process
>     instanceVariableNames: 'suspendedContext priority myList threadId
> effectiveProcess name island env'
>     classVariableNames: ''
>     poolDictionaries: ''
>     category: 'Kernel-Processes'
> while Pharo 60257 has ivars...
>   Link subclass: #Process
>     instanceVariableNames: 'suspendedContext priority myList name env
> effectiveProcess terminating'
>     classVariableNames: 'InheritablePSKeys PSKeys PSKeysSema'
>     package: 'Kernel-Processes'
> where the threadId variable "is used by multi-threaded CogVMs to
> control process-to-thread binding. It's required to be the fourth
> instance variable."
> So first a side question... Should Pharo add threadId?
> And my main question, can I lock effectiveProcess in as the fifth
> instance variable so OwnedLock primitive can access it from the VM ?

You can, but I would hope you wouldn't :-).

cheers -ben

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20161017/221386f2/attachment.htm

More information about the Vm-dev mailing list