static strings -- little fun on the side

[Harald Welte]

Hi Neels,

I haven't yet ready our code, just briefly read your e-mail.

One more radical option (much more costly, for sure) would be to
introcue somthing like a "packet processing talloc context" and use
dynamic allocations:

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.

This is actually a bit inspired from wireshark, where AFAIK you can also
alloctate dynamic memory within the context of a given packet.

Sure, dynamic allocations are more expensive.  But in the end, aside
from osmo-pcu on ARM926EJS sysmoBTS 1002, we've never really seen real
performance problems in the use cases so far.  And as you indicate, if
the logging is turned off, the allocations would never be made.  And we
can make it OOM free by simply returning a static const char * "<OOM!>"
in case the allocation should ever fail.

One might be able to get similar but slightly different semantics by
attaching those strings to the 'msgb' that's currently being processed.
At some point the msgb will be released.  Depending on the use case, the
memory would be allocated for more than the current fd-callback, e.g. in
case of queueing the msgb somewhere.

Regards,
	Harald
-- 
- 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)