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/.
Harald Welte laforge at gnumonks.orgHi Neels,
On Thu, Mar 21, 2019 at 02:24:30AM +0100, Neels Hofmeyr wrote:
> Talking of features, another idea comes to mind: freeing of FSM instances. I
> more often than not have the problem that a child FSM is freeing, telling the
> parent about it, then the parent decides to free because the child's result
> signalled some end, and then we have a double free because the child was
> allocated with the parent as talloc context, the parent has just deallocated,
> but after the child's cleanup is through, the fsm code wants to also deallocate
> the child.
That just sounds like a bug and it should be fixed? The question is whether
we want to mandate all child contexts to be allocated from within a parent. If
so, then whatever mechanism to prevent this could / should become part
of the fsm core.
> In these situations I so far need to introduce checks that prevent
> the parent from freeing until the children are completely finished with their
> actions -- for example, avoid signalling end from the cleanup function or event
> handling yet, instead completely rely on the parent_term_event, which is
> dispatched only after the child was freed.
I wonder if those checks could be made part of the core. Do you have a
concrete code example to look at?
> With a volatile context, when an FSM instance should go away I could
> reparent it to the volatile context, it will be cleaned up once all
> event handling is through, and I avoid running into double free by
> accident. It would probably have to be integrated in the fsm.c
> deallocation code.
that's of course also an option. It actually reminds me a bit of RCU (read-copy-update)
in the Linux kernel, where a similar 'delay any actual free() until all possible
users have moved beyond a given 'scheduling point' is used as part of a rather
ingenious and complex lock-less synchronization mechanism.
> ...are we talking about a libosmocore 2.0 now?
I think the volatile context alone is not sufficient for such a large
jump. But let's see where we end up.
--
- Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)