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
signature.asc
Description: PGP signature
