mpv/ta
wm4 36dd2348a1 ta: destroy/free children in reverse order
This matters when talloc allocations set destructors. Before this
commit, destructors were called in the same order as they were added to
the parent allocations. Now it happens in reverse order.

I think this makes more sense. It's reasonable to assume that an
allocation that was added later may depend on any of the previous
allocations, so later additions should be destroyed first. (Of course
other orders are entirely possible too.)

Hopefully this doesn't fix or break anything, but I can't be sure (about
either of those). It's risky. (Then why do it?)

The destructor of a parent allocation is called before its children. It
makes sense and must stay this way, because in most cases, the
destructor wants to access the children.

This is a reason why I don't really like talloc (it wasn't my idea to
use talloc, is my excuse). Quite possible that destructors should be
removed from talloc entirely. Actually, this project should probably be
rewritten in Rust (or a better language), but that would be even more of
a pain; also, I think this is just the right level of suffering and
punishment.
2019-09-19 20:37:05 +02:00
..
README
ta.c ta: destroy/free children in reverse order 2019-09-19 20:37:05 +02:00
ta.h
ta_talloc.c
ta_talloc.h
ta_utils.c

README

TA ("Tree Allocator") is a wrapper around malloc() and related functions,
adding features like automatically freeing sub-trees of memory allocations if
a parent allocation is freed.

Generally, the idea is that every TA allocation can have a parent (indicated
by the ta_parent argument in allocation function calls). If a parent is freed,
its child allocations are automatically freed as well. It is also allowed to
free a child before the parent, or to move a child to another parent with
ta_set_parent().

It also provides a bunch of convenience macros and debugging facilities.

The TA functions are documented in the implementation files (ta.c, ta_utils.c).

TA is intended to be useable as library independent from mpv. It doesn't
depend on anything mpv specific.

Note:
-----

mpv doesn't use the TA API yet for two reasons: first, the TA API is not
necessarily finalized yet. Second, it should be easily possible to revert
the commit adding TA, and changing all the code would not allow this.

Especially the naming schema for some TA functions is still somewhat
undecided. (The talloc naming is a bit verbose at times.)

For now, mpv goes through a talloc wrapper, which maps the talloc API to TA.
New code should still use talloc as well. At one point, all talloc calls
will be replaced with TA calls, and the talloc wrapper will be removed.

Documentation for the talloc API is here:

    http://talloc.samba.org/talloc/doc/html/modules.html

There are some minor differences with mpv's talloc bridge. mpv calls abort()
on allocation failures, and the talloc_set_destructor() signature is slightly
different. libtalloc also has a weird 256MB limit per allocation. The talloc
wrapper supports only a strict subset of libtalloc functionality used by mpv.