Hi. - primitiveEnterCriticalSection returns true if section is already entered inside same Process (when recursive call happens). It returns false when new lock on critical section acquired - primitiveTestAndSetOwnershipOfCriticalSection returns true if section is already entered inside same Process (when recursive call happens). It returns false when new lock on critical section acquired. It returns nil when section locked by other process. Users of this code must handle process termination carefully which required local variable which track current lock state: [lockState := section primitiveEnterCriticalSection. some code] ensure: ["condition around lockState" section primitiveExitCriticalSection ] With current logic of primitives it is not easy to give this variable intuitive name. You can't name it exitRequired or sectionEnteredHere because primitive returns opposite value. Can we invert this primitive return values? It will make users code cleaner and easy to understand. This primitives are not used in Pharo or Squeak yet. I push change for Pharo. But now I have thoughts that it is better to change primitives before we will start use it. What you think? |
Hi Denis, I'm sorry but I already moved Squeak trunk over to the new primitives (and 3DICC's Terf system has been using them since 2008/2009). You can invert via eg false == self primitiveEnterCriticalSection At some future date we could add revised primitives with new primitive numbers. But the current primitives are set. Sorry. _,,,^..^,,,_ (phone) > On Jan 11, 2016, at 8:35 AM, Denis Kudriashov <[hidden email]> wrote: > > Hi. > > Current logic is: > > - primitiveEnterCriticalSection returns true if section is already entered inside same Process (when recursive call happens). It returns false when new lock on critical section acquired > - primitiveTestAndSetOwnershipOfCriticalSection returns true if section is already entered inside same Process (when recursive call happens). It returns false when new lock on critical section acquired. It returns nil when section locked by other process. > > Users of this code must handle process termination carefully which required local variable which track current lock state: > > [lockState := section primitiveEnterCriticalSection. > some code] > ensure: ["condition around lockState" section primitiveExitCriticalSection ] > > With current logic of primitives it is not easy to give this variable intuitive name. You can't name it exitRequired or sectionEnteredHere because primitive returns opposite value. > > Can we invert this primitive return values? It will make users code cleaner and easy to understand. > > This primitives are not used in Pharo or Squeak yet. I push change for Pharo. But now I have thoughts that it is better to change primitives before we will start use it. > > What you think? |
Hi Eliot. 2016-01-11 18:00 GMT+01:00 Eliot Miranda <[hidden email]>:
Ok. I can not wait this for now. So we will integrate my changes into Pharo (I hope) |
On Mon, 11 Jan 2016, Denis Kudriashov wrote: > Ok. I can not wait this for now. > So we will integrate my changes into Pharo (I hope) That was the time when Pharo finally separated at the VM level. Levente |
no he is not. he is talking about the image. do not drop bombs :) Esteban > On 11 Jan 2016, at 22:35, Levente Uzonyi <[hidden email]> wrote: > > On Mon, 11 Jan 2016, Denis Kudriashov wrote: > >> Ok. I can not wait this for now. >> So we will integrate my changes into Pharo (I hope) > > That was the time when Pharo finally separated at the VM level. > > Levente |
In reply to this post by Levente Uzonyi
2016-01-11 22:35 GMT+01:00 Levente Uzonyi <[hidden email]>:
Sorry. I mean I will not wait primitive changes and just push my image code with current semantic |
Free forum by Nabble | Edit this page |