On 21 February 2013 12:59, [email protected] <[email protected]> wrote: > Nice to know about this Smalltalk session. Didn't knew about that. > > BTW, did a debug it and it froze my image in a BlockClosure>>newProcess > wait for 1 hour and come back :)
> Phil > > 2013/2/21 Igor Stasenko <[email protected]>: >> On 21 February 2013 12:36, Sven Van Caekenberghe <[email protected]> wrote: >>> Yes, I think you are right: the ambiguity is plain wrong, and even then not >>> saving and continuing them sounds reasonable. >>> >>> But what about the inverse: you schedule something that should happen every >>> hour or every day, you save/restart the image and with the new approach >>> these would all run immediately, right ? >>> >> >> well, but in this case, once you will know that all delays is released >> on image restart, you can always check for session change before doing >> any action.. >> for example: >> >> [ >> | session | >> session := Smalltalk session. >> >> 1 hour asDelay wait. >> >> "is session changed?" >> session == Smalltalk session ifFalse: [ "perhaps we should abandon >> the loop here and reload/reinitialize stuff in some higher layers of >> code" ]. >> >> self doSomething. >> >> ] repeat. >> >> >> Why this "perhaps we should abandon the loop here and >> reload/reinitialize stuff in some higher layers of code".. >> because any resident code (like forked process with infinite loop) is >> a common source of nasty problems, >> unreliable behavior and usually hard to debug (especially over >> multiple sessions or when you changing the code which it should run).. >> >> And to my thinking, writing a proper session-aware code is a way to >> go, instead of relying on ambiguous things. >> >>> So not only would you kill delays that are too short (reasonable), but >>> collapse the longer ones. >>> >>> In terms of design: I think the different behaviors should be implemented >>> with different objects. >>> >>> On 21 Feb 2013, at 12:28, Igor Stasenko <[email protected]> wrote: >>> >>>> Hi. >>>> >>>> There is one thing which is IMO an over-engineering artifact: >>>> - when system goes down (image shutdown), all currently scheduled >>>> delays are "saved" >>>> and then when image starting up they are rescheduled again to keep >>>> waiting what time is left for delay.. >>>> >>>> But the problem is that it does not takes into account the total time >>>> an image was frozen, and the requirement is quite ambiguous: >>>> >>>> - if you put a process on a delay for 5 minutes, then immediately >>>> save image, and then restart it 10 minutes (or 1 year) after, >>>> should this delay keep waiting for 4 +x seconds which is left? Or >>>> should we consider this delay as utterly expired? >>>> (and as you can see, the answer is different, if we counting time >>>> using real, physical time, or just image uptime). >>>> >>>> And why counting image uptime? Consider use cases, like connection >>>> timeout.. it is all about >>>> real time , right here , right now.. will it matter to get socket >>>> connection timeout error when you restart some image 1 year after? >>>> Please, give me a scenario, which will illustrate that we cannot live >>>> without it and should count image uptime for delays, because i can't >>>> find one. >>>> >>>> If not, then to my opinion, and to simplify all logic inside delay >>>> code, i would go straight and declare following: >>>> - when new image session starts, all delays, no matter for how long >>>> they are scheduled to wait are considered expired (and therefore all >>>> waiting processes >>>> is automatically resumed). >>>> >>>> Because as tried to demonstrate, the meaning of delay which spans over >>>> multiple image sessions is really fuzzy and i would be really >>>> surprised to find a code >>>> which relies on such behavior. >>>> >>>> This change will also can be helpful with terminating all processes >>>> which were put on wait for too long (6304550344559763 milliseconds) by >>>> mistake or such. >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.
