On 19 September 2016 at 11:06, Martin Pieuchot <m...@openbsd.org> wrote: > On 19/09/16(Mon) 13:47, David Gwynne wrote: >> [...] >> id rather not grow the timeout (or task for that matter) apis just >> yet. theyre nice and straightforward to read and understand so far. > > So better introduce a new API, right? > >> for this specific problem can we do a specific fix for it? the diff >> below is equiv to the timeout_set_proc change, but implements it >> by using explicit tasks that are called by the timeouts from a >> common trampoline in the network stack. > > Is it really a specific problem? We already encounter this for the > linkstate and the watchdog. > > I'm not convinced by this approach. I don't understand why: > - adding a task in every data structure is worth it > - introducing a new if_nettmo_* make things simpler > > So there's something which isn't explain in this email. > > And I'll bet that in the upcoming years we're going to stop using soft > interrupts. Meaning that timeout handlers will always have a stack > available. If/when this happens, it will be easier to do: > > s/timeout_set_proc/timeout_set/ >
FWIW, I agree with mpi on this. As a temporary change his approach is sound. I would also like to know what prevents us from executing all timeouts in a thread context now? serial drivers with softtty line discipline entanglement?
