4 Mar
2019
4 Mar
'19
3:11 p.m.
On Tue, Feb 26, 2019 at 11:19:14PM +0100, Harald Welte wrote:
So basically
1) every time we come out of select() and call a filedescriptor callback,
we would create a new talloc context.
2) any code, including those that want to print messages to buffers, etc.
could allocate memory from that context without having to care about
releasing it
3) once we return from the file descriptor call-back, we talloc_free()
that "master" context, taking with it all the child allocations hat may
have
been allocated underneath.
I like that approach.
If dyn allocations become a problem there could even be a large block that is
re-used across select() cycles, and enlarged if necessary but otherwise staying
in place. Probably will not be a problem though.
One might be able to get similar but slightly
different semantics by
attaching those strings to the 'msgb' that's currently being processed.
That would complicate API signatures, e.g. things like osmo_plmn_name()? I
think that makes sense only for msgb_hexdump(), where a msgb is already part of
the signature. But I'd say just using the same mechanism would be fine.
can make it OOM free by simply returning a static
const char * "<OOM!>"
Yes, probably better than a program abort.
~N