On Tue, Feb 26, 2019 at 11:19:14PM +0100, Harald Welte wrote:
So basically
- every time we come out of select() and call a filedescriptor callback, we would create a new talloc context.
- 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
- 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