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/.

Pablo Neira Ayuso pablo at gnumonks.org
Sun Nov 13 00:28:30 UTC 2011


On Sat, Nov 12, 2011 at 11:07:03PM +0100, Sylvain Munaut wrote:
> > The patch attached should recover the former behaviour, sorry for
> > missing this case.
> 
> Oops, sorry, we actually continued on IRC.
> 
> Look at the first few commits of
> http://cgit.osmocom.org/cgit/libosmocore/log/?h=sylvain/for_jolly
> 
> They bring in some fixes/cleanups from the kernel for rbtree then
> something that fixes the timer. This patch keeps the list head intact
> and just remove the timer from the tree and re-adds it at the right
> place.

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.

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




More information about the OpenBSC mailing list