Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Don Y Newsgroups: comp.arch.embedded Subject: Re: Dealing with "past" events Date: Tue, 5 Nov 2024 17:05:23 -0700 Organization: A noiseless patient Spider Lines: 135 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 06 Nov 2024 01:05:30 +0100 (CET) Injection-Info: dont-email.me; posting-host="0110b6d8c984a836dd82208ad7728387"; logging-data="1865198"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/nDkuX3EkEVaWxZuxM7ew9" User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cancel-Lock: sha1:RAtG0rkUjN1buzczwxgsYMOp5ls= Content-Language: en-US In-Reply-To: Bytes: 6956 On 11/5/2024 4:21 PM, George Neuner wrote: >>> It reasonably is safe to assume that a "do it now" event should be >>> executed as soon as possible, even if was delayed several seconds in >>> the scheduling. >>> >>> But beyond that you're speculating. >>> >>> Unix 'cron', 'at', etc. are not particularly good examples to follow - >>> they are too simplistic. The set of options available to the Windows >>> scheduler is better (though not exhaustive), but IMO most of the >>> "options" should be mandatory parameters that must be provided in >>> order to schedule an event. >> >> Those are exposed to users. I'm looking at OS hooks that a developer >> would exploit in an API (as above). > > Not the point. My comment was about what options / parameters are > available to the schedule(r). > > >> This opens the possibility of another class of potential errors: >> schedule(event_time) >> ... >> schedule(event_time+delta) >> ... >> what if now > event_time + delta? If the developer had naively assumed >> the first event would have completed within "delta" (instead of providing >> a definite interlock on the scheduling of the second event), then you >> could end up allowing both events to be "immediately" scheduled with >> no clear indication of whether the first would complete before the >> second got started. (i.e., a race baked into the implementation) >> >>>> I've argued that the OS shouldn't special-case such activities. >>>> If you request something to happen in the past, then the OS >>>> should just act as if it has *just* happened, regardless as to >>>> whether you were a microsecond "late" in issuing your request >>>> or *years*! In particular, the OS shouldn't dismiss such request >>>> unilaterally -- or, throw an error to alert the issuer to the >>>> *apparent* inconsistency. >>> >>> I think it should be an error for a /timed/ (not "now") event to be >>> scheduled past any possible execution time. An event that repeats >>> could be scheduled past its initial run time, but there should be at >>> least one repetition in the /future/. >> >> Run the speech recognizer's retraining algorithm at 01:00AM (because >> no one is likely to be speaking, then). Ah, but shit happened and >> we couldn't get around to it until 1:30... should we abort that? > > Now you're not paying attention: I suggested above to look at the > Windows scheduler. One of the options (paraphrased) is "run asap if > missed". > > But things like that should be the user / programmer choice based on > the task to be performed - not a system policy. This goes beyond "system policy" (which would be some default way to handle these types of incidents) Did you miss: >> I argue that, if the developer expects such a condition to >> occur *or* there is a significant consequence to allowing >> it to be unconditionally scheduled when he would prefer it >> NOT be, then he should condition his invocation of the >> event instead of burdening the syscall with yet another >> option: >> >> if !(now > event_time) >> schedule(event_time) >> >> This also draws attention to the fact that the event should >> NOT be scheduled in that particular case -- in a more obvious >> way than some parameter to an embelished syscall. The variety of different conditions that could be practical would needlessly complicate a syscall. E.g., to handle: >> schedule(event_time) >> ... >> schedule(event_time+delta) >> ... one might condition the *second* schedule() with: if (first_scheduled) schedule(event_time+delta) >> If you treat the tasks in a system as being flexible in their >> scheduling (which is inherent in almost all multitasking systems... >> you can't be assured when ANY task *actually* executes), then you >> can't define hard limits as to how "late" something can happen. > > Again the Windows scheduler: (paraphrased) there are options to > "wait