new timer code: semantics of osmo_timer_schedule for already scheduled timer

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Sylvain Munaut 246tnt at gmail.com
Sun Nov 13 09:07:58 UTC 2011


> Hm, I think I found one weird scenario which is not handled fine with
> your patch.
>
> Say you have two timers A and B. Assume both expire on the same time
> (and they are inserted in the eviction list in this order, first A,
> then B). Then, A re-schedules B in its callback. B is reinserted
> in the tree, however, B is still in the eviction list.
>
> With aeeb7070f84437aa608a3d843346b1efa916d175, since we don't
> touch the list head. B will be removed from the tree, but I think it
> should remain there as it has been rescheduled.
>
> Yes, this scenario is strange, but I think we try to cover all possible
> situations. So I think my patch should be applied instead.

You're right. Even worse, with my patch during the scan of the
eviction list, we'll call the new B callback with the new B data at
the old time.


> Thanks for collecting the patches that went into rbtree.c in the linux
> kernel, btw.

fyi, I skipped the few last ones that add a new "augmented rb tree"
functionality that we don't need (yet?).

Cheers,

   Sylvain




More information about the OpenBSC mailing list