buffer allocation/destruction
Rob Landley
rob at landley.net
Tue Aug 30 01:06:44 UTC 2005
On Monday 29 August 2005 17:35, Bernhard Fischer wrote:
> Hi,
>
> I'm in the process of making more applets peruse RESERVE_CONFIG_BUFFER.
>
> I'm not sure how to deal with the destruction of buffer in the case of
> FEATURE_CLEANUP, though.
There's a more fundamental problem.
bb_perror_msg_and_die() and friends call exit(), and our code is littered with
calls to that. Any attempt at making FEATURE_CLEANUP comprehensive (which is
needed to use setjmp/longjmp in place of fork/exit) has to deal with that
mess, where our exit code that does the cleanup simply never gets called.
There's a couple ways we can do this. Our FEATURE_CLEANUP code can register
an atexit() function (like sed has been doing since before I first touched
it). We can also have special allocation functions that create a linked list
of memory we've allocated, which can be freed with a single call that
traverses the list (possibly with a "since" pointer so it only frees
sufficiently recent allocations). Both are pretty ugly, and neither is quite
compatible with the "free it as we no longer need it" method we've been
using.
This is major surgery. Dealing with CONFIG_BUFFER, FEATURE_CLEANUP, and
FORK_LONGJMP (or whatever it's going to be called) is actually one big
tangled mess that probably has to be done all at once.
Now on the bright side, if we convert more stuff to allocating on the stack,
then the clean_up case gets easier and easier. And allocating stuff on the
stack saves us the overhead of a function call, thus making the code smaller.
But I'm under the impression there are downsides to this; broken boxes that
have very limited stack space.
Erik would know the details...?
Rob
More information about the busybox
mailing list