On Fri, Feb 19, 2021 at 9:35 AM Gedare Bloom <ged...@rtems.org> wrote: > > On Thu, Feb 18, 2021 at 11:59 PM Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: > > > > On 18/02/2021 18:49, Gedare Bloom wrote: > > > > >> + executing->cpu_time_budget = normal_cpu_time_budget ; > > >> + executing->budget_algorithm = normal_budget_algorithm ; > > >> + prev_is_preemptible = executing->is_preemptible; > > > 'prev' is unclear here, especially since we have "normal" as a > > > previous mode also. Maybe, 'asr_is_preemptible' is better? > > > > > No, normal is not necessarily the previous mode. The ASR handler may > > change the mode. I can name it previous_is_preemptible if you don't like > > the prev. asr_is_preemptible doesn't fit, since this is the mode set up > > before the ASR handler is called.
I think I misunderstood this. Is it guaranteed that after the ASR returns, executing->is_preemptible is the same as it was before the ASR? In that case, maybe the prev_is_preemptible should be copied from executing->is_preemptible *before* making the ASR call? > > > > I guess I just get a little confused between what "previous" means in > this case. Normal mode is "previous" to the ASR call, and you are > copying the executing->is_preemptible that may have been changed by > the ASR, so what is this "previous" to? It doesn't make sense to me. > > I don't mind 'prev' as an abbreviation of previous. I just don't know > what this is_preemptible variable is "previous" to? > > I guess there are three points here... > > Before the ASR > In the ASR > Dispatching after the ASR > Returning to the original caller > > So, you can't say "previous" since there are 2 things in the middle. > > > -- > > embedded brains GmbH > > Herr Sebastian HUBER > > Dornierstr. 4 > > 82178 Puchheim > > Germany > > email: sebastian.hu...@embedded-brains.de > > phone: +49-89-18 94 741 - 16 > > fax: +49-89-18 94 741 - 08 > > > > Registergericht: Amtsgericht München > > Registernummer: HRB 157899 > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > > Unsere Datenschutzerklärung finden Sie hier: > > https://embedded-brains.de/datenschutzerklaerung/ > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
