[Cuis-dev] [QUESTION] Delays after image startup

[Juan Vuletich]

Hi Gerald,

(inline)
On 7/19/2023 5:06 PM, Gerald Klix via Cuis-dev wrote:
> Hi Juan,
>
> thanks for your answer and apologies for my late reply;
> I was on the road again.
>
> Please see below.
>
> On 7/17/23 4:27 PM, Juan Vuletich wrote:
>> ...
>> I think that all Delays that expired when the image was not running 
>> should simply be discarded at startup. Otherwise there is a real risk 
>> of the image not starting again, or getting stuck.
>>
> To me this makes sense. Additionally we could get rid of the
> complicated logic in the category snapshotting  of class Delay.
> Do you want to terminated the associated processes, too?

Not sure. Killing user processes sounds like way too much. I googled a 
bit and found this: "A delay in progress when an image snapshot is saved 
is resumed when the snapshot is re-started." here: 
http://wiki.squeak.org/squeak/3134

If this is already the behavior we have, maybe it's not worth changing it.

>
>> I also think that saving an image with suspended Delays is not a good 
>> idea...
>>
> In that case, we can get rid of the delays when saving the image.
> Again the question about the associated processes arises.
>

If I was writing an application that uses Delays, I guess I'd think 
carefully before letting them exist in snapshots. Anyway, it is up to 
the app developer code. I don't see a good reason for Cuis to force a 
particular strategy on everybody.

> The current semantics of delays in saved images is surprising
> and probably unintentional; at least it needs some words
> of explanations in Delay's class comment.

That comment in the Wiki is not in Squeak either. I found nothing in the 
Blue Book or Inside Smalltalk. But Smalltalk-80 has two methods 
Delay>>preSnapshot y Delay>>postSnapshot that seem to do as the wiki 
says. Perhaps we'd improve Delay class comment.

>
> Any how, I implemented Alarms for items in a todo-list with delays.
> The solution for the aforementioned problem is to "reschedule"
> all the alarms when starting the image. "Reschedule" means
> terminated the old process waiting on the delay and create
> a new one, if the alarm still lies in the future.
> Otherwise change the alarm's due time to 5 seconds
> in the future, to alert the user shortly after image startup.
>
> I implemented this behavior using initClassCachedState.
> This way the alarms are rescheduled even when
> I just save the image.
>
>
> Best Regards,
>
> Gerald

Yes, applications will do what suits them best.

Cheers,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich