RFC: talloc contexts / automatic free at select loop

[Harald Welte]

Hi Pau,

On Wed, Mar 20, 2019 at 12:54:11PM +0100, Pau Espin Pedrol wrote:
> First of all, I'm not against addition of this "select scoped talloc
> context", and it's fine for me to merge if others find it's a really handy
> feature. But I have the feeling it really adds unneeded extra complexity and
> scenarios to take care in the code. New ways to get shot on your knee,
> having to use talloc_steal() and talloc_reparent(). Not sure if the benefits
> are worth the effort and increase of complexity.

What is your solution to neels' recently described problem with msgb
ownership in successful/error cases when passing msgb's between different
subsystems (in his example the libosmo-sccp sigtran stack) ?

I think this is where the beauty of this system really shows.

But maybe it's possible even without the 'select scoped context' with keeping
allocations all global (like now) and using talloc_reference()?  This way the
default behavior would be an explicit free() by the caller, i.e.


	msg = msgb_alloc()
	/* put some data in the msgb, e.g. received from socket */
	call_some_other_subsystem(msg);
	talloc_unlink(msg); /* cannot use {msgb,talloc}_free() anymore! */

And if that other_subsystem would want to keep msgb around, they would have
to talloc_reference() the msgb, thereby having two parents.  The msgb would
only be free'd at the last talloc_unlink().   But that turns the talloc tree
into a graph and to me it really messes up things.  Also the fact that you
can no longer use talloc_free() makes things very complicated.  So not really
an option.

-- 
- 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)