[Pharo-project] Delay bug
Hi, When using a Delay and saving the image, the delay becomes stupidly broken. Look at this: With the following code Object subclass: #DelayBug instanceVariableNames: 'delay process' classVariableNames: '' poolDictionaries: 'private' category: 'DelayBug' start delay := Delay forMilliseconds: 300. process := [ [ Transcript logCr: 'test'. delay wait . false ] whileFalse: [ ] ] fork. - Then evaluate. *db := DelayBug new.* *db start.* - inspect *db instVarAt: 'delay'.* * * The delay seems ok. - save the image The delay has a stupid time to be finished :/ Guille
that is indeed very strange. I can fully reproduce your issues. that means all delays are corrupted when saving the image? :D However this has only nasty side-effects for Delays that are currently used for waiting, otherwise the endTime will simply be refreshed when waiting the next time. => serious bug report! On 2012-11-29, at 11:55, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi,
When using a Delay and saving the image, the delay becomes stupidly broken. Look at this:
With the following code
Object subclass: #DelayBug instanceVariableNames: 'delay process' classVariableNames: '' poolDictionaries: 'private' category: 'DelayBug'
start delay := Delay forMilliseconds: 300. process := [ [ Transcript logCr: 'test'. delay wait . false ] whileFalse: [ ] ] fork.
- Then evaluate.
*db := DelayBug new.* *db start.*
- inspect
*db instVarAt: 'delay'.* * * The delay seems ok.
- save the image
The delay has a stupid time to be finished :/
Guille
Cool it's not just me and a strange setup :) tx. I'll open an issue then. On Thu, Dec 6, 2012 at 2:59 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
that is indeed very strange. I can fully reproduce your issues.
that means all delays are corrupted when saving the image? :D However this has only nasty side-effects for Delays that are currently used for waiting, otherwise the endTime will simply be refreshed when waiting the next time.
=> serious bug report!
On 2012-11-29, at 11:55, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi,
When using a Delay and saving the image, the delay becomes stupidly broken. Look at this:
With the following code
Object subclass: #DelayBug instanceVariableNames: 'delay process' classVariableNames: '' poolDictionaries: 'private' category: 'DelayBug'
start delay := Delay forMilliseconds: 300. process := [ [ Transcript logCr: 'test'. delay wait . false ] whileFalse: [ ] ] fork.
- Then evaluate.
*db := DelayBug new.* *db start.*
- inspect
*db instVarAt: 'delay'.* * * The delay seems ok.
- save the image
The delay has a stupid time to be finished :/
Guille
http://code.google.com/p/pharo/issues/detail?id=7106&thanks=7106&ts=13548031... On Thu, Dec 6, 2012 at 3:10 PM, Guillermo Polito <guillermopolito@gmail.com>wrote:
Cool it's not just me and a strange setup :) tx. I'll open an issue then.
On Thu, Dec 6, 2012 at 2:59 PM, Camillo Bruni <camillobruni@gmail.com>wrote:
that is indeed very strange. I can fully reproduce your issues.
that means all delays are corrupted when saving the image? :D However this has only nasty side-effects for Delays that are currently used for waiting, otherwise the endTime will simply be refreshed when waiting the next time.
=> serious bug report!
On 2012-11-29, at 11:55, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi,
When using a Delay and saving the image, the delay becomes stupidly broken. Look at this:
With the following code
Object subclass: #DelayBug instanceVariableNames: 'delay process' classVariableNames: '' poolDictionaries: 'private' category: 'DelayBug'
start delay := Delay forMilliseconds: 300. process := [ [ Transcript logCr: 'test'. delay wait . false ] whileFalse: [ ] ] fork.
- Then evaluate.
*db := DelayBug new.* *db start.*
- inspect
*db instVarAt: 'delay'.* * * The delay seems ok.
- save the image
The delay has a stupid time to be finished :/
Guille
this is not a bug, but limitation. delay object(s) are not reentrant: means that you shall not use same delay instance multiple times, i.e. delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay wait ] fork ]. instead you shall create a fresh instance for each "delay" intent: 10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ]. -- Best regards, Igor Stasenko.
On 6 December 2012 16:12, Igor Stasenko <siguctua@gmail.com> wrote:
this is not a bug, but limitation. delay object(s) are not reentrant: means that you shall not use same delay instance multiple times, i.e.
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay wait ] fork ].
instead you shall create a fresh instance for each "delay" intent:
10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ].
if Delay could implement #copy, then you could write like: delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay copy wait ] fork ]. this is because a Delay has 1:1 correspondence with its semaphore object. and when you scheduling it multiple times, it will end up using same semaphore for all instances of it... and that's why you get weird behavior. -- Best regards, Igor Stasenko.
Wait, all delays are signaled when the image is saved? So, if I have a five minute delay in a process and I save the image 2 seconds later... [ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork. Smalltalk snapshot: true andQuit: false. That is a limitation but is also a bug :/... On Thu, Dec 6, 2012 at 4:15 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:12, Igor Stasenko <siguctua@gmail.com> wrote:
this is not a bug, but limitation. delay object(s) are not reentrant: means that you shall not use same delay instance multiple times, i.e.
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay wait ] fork ].
instead you shall create a fresh instance for each "delay" intent:
10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ].
if Delay could implement #copy, then you could write like:
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay copy wait ] fork ].
this is because a Delay has 1:1 correspondence with its semaphore object. and when you scheduling it multiple times, it will end up using same semaphore for all instances of it... and that's why you get weird behavior.
-- Best regards, Igor Stasenko.
On 6 December 2012 16:28, Guillermo Polito <guillermopolito@gmail.com> wrote:
Wait, all delays are signaled when the image is saved? So, if I have a five minute delay in a process and I save the image 2 seconds later...
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork.
Smalltalk snapshot: true andQuit: false.
That is a limitation but is also a bug :/...
no.. they are not.. sorry my first comment was not correct.. i corrected myself in followup :)
On Thu, Dec 6, 2012 at 4:15 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:12, Igor Stasenko <siguctua@gmail.com> wrote:
this is not a bug, but limitation. delay object(s) are not reentrant: means that you shall not use same delay instance multiple times, i.e.
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay wait ] fork ].
instead you shall create a fresh instance for each "delay" intent:
10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ].
if Delay could implement #copy, then you could write like:
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay copy wait ] fork ].
this is because a Delay has 1:1 correspondence with its semaphore object. and when you scheduling it multiple times, it will end up using same semaphore for all instances of it... and that's why you get weird behavior.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:28, Guillermo Polito <guillermopolito@gmail.com> wrote:
Wait, all delays are signaled when the image is saved? So, if I have a five minute delay in a process and I save the image 2 seconds later...
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork.
Smalltalk snapshot: true andQuit: false.
That is a limitation but is also a bug :/...
no.. they are not.. sorry my first comment was not correct.. i corrected myself in followup :)
I understand the 1 delay<->1 semaphore. But I am not creating several ones. What if a second process saves the image while another one is waiting? This piece of code shows that problem. [ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork. Smalltalk snapshot: true andQuit: false. It will not honor the delay :/
On Thu, Dec 6, 2012 at 4:15 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 6 December 2012 16:12, Igor Stasenko <siguctua@gmail.com> wrote:
this is not a bug, but limitation. delay object(s) are not reentrant: means that you shall not use same delay instance multiple times, i.e.
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay wait ] fork ].
instead you shall create a fresh instance for each "delay" intent:
10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ].
if Delay could implement #copy, then you could write like:
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay copy wait ] fork ].
this is because a Delay has 1:1 correspondence with its semaphore
object.
and when you scheduling it multiple times, it will end up using same semaphore for all instances of it... and that's why you get weird behavior.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 6 December 2012 16:44, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:28, Guillermo Polito <guillermopolito@gmail.com> wrote:
Wait, all delays are signaled when the image is saved? So, if I have a five minute delay in a process and I save the image 2 seconds later...
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork.
Smalltalk snapshot: true andQuit: false.
That is a limitation but is also a bug :/...
no.. they are not.. sorry my first comment was not correct.. i corrected myself in followup :)
I understand the 1 delay<->1 semaphore. But I am not creating several ones. What if a second process saves the image while another one is waiting?
This piece of code shows that problem.
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork. Smalltalk snapshot: true andQuit: false.
It will not honor the delay :/
ah.. ok. then that's indeed a problem. about not honors: is it signal it prematurely or not signaling it at all? -- Best regards, Igor Stasenko.
On Thu, Dec 6, 2012 at 5:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:44, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 6 December 2012 16:28, Guillermo Polito <guillermopolito@gmail.com> wrote:
Wait, all delays are signaled when the image is saved? So, if I have a five minute delay in a process and I save the image 2 seconds later...
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork.
Smalltalk snapshot: true andQuit: false.
That is a limitation but is also a bug :/...
no.. they are not.. sorry my first comment was not correct.. i corrected myself in followup :)
I understand the 1 delay<->1 semaphore. But I am not creating several ones. What if a second process saves the image while another one is waiting?
This piece of code shows that problem.
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork. Smalltalk snapshot: true andQuit: false.
It will not honor the delay :/
ah.. ok. then that's indeed a problem. about not honors: is it signal it prematurely or not signaling it at all?
prematurely :)
-- Best regards, Igor Stasenko.
On 06.12.2012 17:15, Guillermo Polito wrote:
On Thu, Dec 6, 2012 at 5:02 PM, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote:
On 6 December 2012 16:44, Guillermo Polito <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>> wrote: > > > On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua@gmail.com <mailto:siguctua@gmail.com>> wrote: >> >> On 6 December 2012 16:28, Guillermo Polito <guillermopolito@gmail.com <mailto:guillermopolito@gmail.com>> >> wrote: >> > Wait, all delays are signaled when the image is saved? So, if I have a >> > five >> > minute delay in a process and I save the image 2 seconds later... >> > >> > [ d := 5 minutes asDelay. >> > d wait. >> > Transcript logCr: 'asd' ] fork. >> > >> > Smalltalk snapshot: true andQuit: false. >> > >> > That is a limitation but is also a bug :/... >> > >> no.. they are not.. sorry my first comment was not correct.. i >> corrected myself in followup :) > > > I understand the 1 delay<->1 semaphore. But I am not creating several ones. > What if a second process saves the image while another one is waiting? > > This piece of code shows that problem. > > [ d := 5 minutes asDelay. > d wait. > Transcript logCr: 'asd' ] fork. > Smalltalk snapshot: true andQuit: false. > > It will not honor the delay :/ > ah.. ok. then that's indeed a problem. about not honors: is it signal it prematurely or not signaling it at all?
prematurely :)
Hmmm, Delay >> startUp was modified recently, to restart the timer event loop. The same doesn't happen in a 1.4 where that is absent. Dunno whatever it was supposed to fix, but since the change initials indicate one Guillermo Polito was involved, he might be around to answer what might break if it is reverted :) Cheers, Henry
On Fri, Dec 7, 2012 at 1:05 PM, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:
On 06.12.2012 17:15, Guillermo Polito wrote:
On Thu, Dec 6, 2012 at 5:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:44, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
On 6 December 2012 16:28, Guillermo Polito <guillermopolito@gmail.com> wrote:
Wait, all delays are signaled when the image is saved? So, if I have
a
five minute delay in a process and I save the image 2 seconds later...
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork.
Smalltalk snapshot: true andQuit: false.
That is a limitation but is also a bug :/...
no.. they are not.. sorry my first comment was not correct.. i corrected myself in followup :)
I understand the 1 delay<->1 semaphore. But I am not creating several ones. What if a second process saves the image while another one is waiting?
This piece of code shows that problem.
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork. Smalltalk snapshot: true andQuit: false.
It will not honor the delay :/
ah.. ok. then that's indeed a problem. about not honors: is it signal it prematurely or not signaling it at all?
prematurely :)
Hmmm, Delay >> startUp was modified recently, to restart the timer event loop. The same doesn't happen in a 1.4 where that is absent. Dunno whatever it was supposed to fix, but since the change initials indicate one Guillermo Polito was involved, he might be around to answer what might break if it is reverted :)
Ha! Nice :). Will have a look.
Cheers, Henry
yes, i also found that it doesn't leaves a critical section correctly, because in #shutdown, before anything it does: AccessProtect wait and in startup it does: AccessProtect := Semaphore new. AccessProtect signal. since it replacing it with a new semaphore, it is not symmetrical (it do not signals same semaphore). So, if there any other process which waits on AccessProtect , it will never have chance to finish waiting and will be blocked forever. On 7 December 2012 13:05, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
On 06.12.2012 17:15, Guillermo Polito wrote:
On Thu, Dec 6, 2012 at 5:02 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:44, Guillermo Polito <guillermopolito@gmail.com> wrote:
On Thu, Dec 6, 2012 at 4:35 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:28, Guillermo Polito <guillermopolito@gmail.com> wrote:
Wait, all delays are signaled when the image is saved? So, if I have a five minute delay in a process and I save the image 2 seconds later...
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork.
Smalltalk snapshot: true andQuit: false.
That is a limitation but is also a bug :/...
no.. they are not.. sorry my first comment was not correct.. i corrected myself in followup :)
I understand the 1 delay<->1 semaphore. But I am not creating several ones. What if a second process saves the image while another one is waiting?
This piece of code shows that problem.
[ d := 5 minutes asDelay. d wait. Transcript logCr: 'asd' ] fork. Smalltalk snapshot: true andQuit: false.
It will not honor the delay :/
ah.. ok. then that's indeed a problem. about not honors: is it signal it prematurely or not signaling it at all?
prematurely :)
Hmmm, Delay >> startUp was modified recently, to restart the timer event loop. The same doesn't happen in a 1.4 where that is absent. Dunno whatever it was supposed to fix, but since the change initials indicate one Guillermo Polito was involved, he might be around to answer what might break if it is reverted :)
Cheers, Henry
-- Best regards, Igor Stasenko.
On 6 December 2012 16:15, Igor Stasenko <siguctua@gmail.com> wrote:
On 6 December 2012 16:12, Igor Stasenko <siguctua@gmail.com> wrote:
this is not a bug, but limitation. delay object(s) are not reentrant: means that you shall not use same delay instance multiple times, i.e.
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay wait ] fork ].
instead you shall create a fresh instance for each "delay" intent:
10 timesRepeat: [ [ 1 seconds asDelay wait ] fork ].
if Delay could implement #copy, then you could write like:
delay := 1 seconds asDelay. 10 timesRepeat: [ [ delay copy wait ] fork ].
this is because a Delay has 1:1 correspondence with its semaphore object. and when you scheduling it multiple times, it will end up using same semaphore for all instances of it... and that's why you get weird behavior.
err.. sorry.. not for "all instances".. since there's only one instance.. so single semaphore will be used to schedule multiple delays (but using single Delay object). and when that semaphore get signaled.. you'll get strange results . if you want to fix that, then it will require disassociating delay object from its semaphore.. the delay will no longer need to hold a 'semaphore' directly by itself but then without it, it will not require to hold any more state than simple Duration. so, to do it right, we will need to make quite some changes in delay scheduling code.. basicaly we will need to create a private object, which will hold 'semaphore + delay object ' pair and put that object in schedule. which at the end will just make same as following: delay := 1 seconds. 10 timesRepeat: [ [ delay asDelay wait ] fork ]. so, to make you happy, just add #wait protocol to Duration: wait ^ self asDelay wait so you can write: delay := 1 seconds. 10 timesRepeat: [ [ delay wait ] fork ]. end of story :) -- Best regards, Igor Stasenko.
participants (4)
-
Camillo Bruni -
Guillermo Polito -
Henrik Sperre Johansen -
Igor Stasenko