Hi 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(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)