Re: [Pharo-users] Dynamically changing code in a safe way
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. Until your code executes *currentBloc value* again, it won't start the new block executing. 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. On Mon, Oct 23, 2017 at 1:53 PM, abdelghani ALIDRA via Pharo-users < pharo-users@lists.pharo.org> wrote:
---------- Forwarded message ---------- From: abdelghani ALIDRA <alidrandco@yahoo.fr> To: <pharo-users@lists.pharo.org> Cc: Bcc: Date: Mon, 23 Oct 2017 20:53:51 +0000 (UTC) Subject: Dynamically changing code in a safe way 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
On 23 Oct 2017, at 23:12 , Richard Sargent <richard.sargent@gemtalksystems.com> 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 <black@cs.pdx.edu> wrote:
On 23 Oct 2017, at 23:12 , Richard Sargent <richard.sargent@ gemtalksystems.com> 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
On 24 Oct 2017, at 22:48 , Peter Uhnák <i.uhnak@gmail.com> 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.
participants (3)
-
Peter Uhnák -
Prof. Andrew P. Black -
Richard Sargent