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.