<html><head></head><body> <div dir="auto">Hi, as I’ve built an EventualTimer, using a Delay, would you consider a Delay class>>#startUp: resume. On resume, grab the image saved time and diff with each Delays’ expireTime, or whatever, and reschedule the diff. Automatic it’s not a problem. We can think about other stuff.</div><div dir="auto"><br></div><div dir="auto">Liscio come<caret></caret> l’olio,</div><div class="protonmail_signature_block" id="protonmail_signature_block"><div>••• rabbit ❤️🔥🐰</div></div> <div class="signature_br" contenteditable="false"><br></div><div class="signature_br" contenteditable="false"><br></div> <div><br></div><div><br></div>On Wed, Jul 19, 2023 at 16:06, Gerald Klix via Cuis-dev <<a class="" href="mailto:On Wed, Jul 19, 2023 at 16:06, Gerald Klix via Cuis-dev <<a href=">cuis-dev@lists.cuis.st</a>> wrote:<blockquote type="cite" class="protonmail_quote"> Hi Juan,<br><br>thanks for your answer and apologies for my late reply;<br>I was on the road again.<br><br>Please see below.<br><br>On 7/17/23 4:27 PM, Juan Vuletich wrote:<br>> On 7/10/2023 7:13 AM, Gerald Klix via Cuis-dev wrote:<br>>> Hi all,<br>>><br>>> I am a bit hesitant to report this as a defect.<br>>><br>>> It looks like that the resumption of<br>>> processes stopped by instances of Delay<br>>> does not always work after image startup.<br>>><br>>> At least for delays that expire during the time<br>>> the image was down, if the clock wraps around<br>>> midnight. Actually these processes seem to be woken<br>>> up at the same time of day, but one day later.<br>>><br>>> Is this the expected behavior?<br>>><br>>><br>>> Best Regards,<br>>><br>>> Gerald<br>><br>> I think that all Delays that expired when the image was not running<br>> should simply be discarded at startup. Otherwise there is a real risk<br>> of the image not starting again, or getting stuck.<br>><br>To me this makes sense. Additionally we could get rid of the<br>complicated logic in the category snapshotting of class Delay.<br>Do you want to terminated the associated processes, too?<br><br>> I also think that saving an image with suspended Delays is not a good<br>> idea...<br>><br>In that case, we can get rid of the delays when saving the image.<br>Again the question about the associated processes arises.<br><br>The current semantics of delays in saved images is surprising<br>and probably unintentional; at least it needs some words<br>of explanations in Delay's class comment.<br><br><br>Any how, I implemented Alarms for items in a todo-list with delays.<br>The solution for the aforementioned problem is to "reschedule"<br>all the alarms when starting the image. "Reschedule" means<br>terminated the old process waiting on the delay and create<br>a new one, if the alarm still lies in the future.<br>Otherwise change the alarm's due time to 5 seconds<br>in the future, to alert the user shortly after image startup.<br><br>I implemented this behavior using initClassCachedState.<br>This way the alarms are rescheduled even when<br>I just save the image.<br><br><br>Best Regards,<br><br>Gerald<br><br><br><br>--<br>Cuis-dev mailing list<br>Cuis-dev@lists.cuis.st<br>https://lists.cuis.st/mailman/listinfo/cuis-dev<br></blockquote></body></html>