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.