Hi,
If I create a class HotSwapping with the instance variable currentBLoc (and the corresponding accessors) and the following methods : HotSwapping>>initialize currentBloc := [ 1 to:50 do: [:index |Transcript show: index. 100 milliSeconds asDelay wait]. Transcript cr. 1000 milliSeconds asDelay wait ] HotSwapping>>run [10 timesRepeat: [ currentBloc value ]] fork I then do : obj := HotSwapping new run The “funny” thing is that, when Transcript starts showing numbers, lets say : 12345678910 (i.e. the bloc is in the middle of its execution), I do obj currentBloc: [Transcript show: ‘Hello’;cr. 1000 milliSeconds asDelay wait ] The Transcript does not stop showing numbers. It shows the Hello message only after the old bloc has finished executing (the entire line of number form 0 to 50 has been printed in the Transcript) So why does not this happen this way? Why the assignment of the new code is delayed until the end of the bloc execution? is it something related to threads execution or does Pharo implement some safety hot swapping mechanisms? Thanks in advance. Abdelghani |
Administrator
|
This is a great question, Abdelghani. It comes down to the meaning of the phrase "everything is an object". When you wrote "currentBloc value", that caused the block [ 1 to:50 do: [:index |Transcript show: index. 100 milliSeconds asDelay wait]. Transcript cr. 1000 milliSeconds asDelay wait ] to evaluate. The fact that you hold a reference to that block elsewhere and change what object is referenced at some point does not change the fact that the block itself is executing.On Mon, Oct 23, 2017 at 1:53 PM, abdelghani ALIDRA via Pharo-users <[hidden email]> wrote:
|
> On 23 Oct 2017, at 23:12 , Richard Sargent <[hidden email]> wrote: > > Imagine if I were to hand you a loaf of bread and tell you to feed it to the dog. If I were then to hand you another loaf of bread, the dog would continue eating the first loaf. We never told the dog to do anything else. If your dog is anything like my dog, telling her to do something else wouldn’t change the situation very much. ;-) Andrew |
> Why the assignment of the new code is delayed until the end of the bloc execution? The assignment is performed immediately, but the old code is still being executed. Once the value was sent to the block, the block started executing and is no longer under the control of the HotSwapping object. On Tue, Oct 24, 2017 at 10:03 PM, Prof. Andrew P. Black <[hidden email]> wrote:
|
> On 24 Oct 2017, at 22:48 , Peter Uhnák <[hidden email]> wrote: > > > Why the assignment of the new code is delayed until the end of the bloc execution? > > The assignment is performed immediately, but the old code is still being executed. Once the value was sent to the block, the block started executing and is no longer under the control of the HotSwapping object. Another way of looking at this is to ask yourself what is the granularity of the think that you are changing. In your original example, you made a new assignment to currentBlock, but the code (operating on the old value of currentBlock) does not re-read this variable each time aroind the loop. It reads it just once, before it starts looping. So changing it afterwards won’t matter. In contrast, suppose that you were to recompile a new version of Trasncript>>#show: while your loop is running. The version that is currently executing would finish, but the next time that #show: is sent to Transcript, you would execute the new version. |
Free forum by Nabble | Edit this page |