buffer allocation/destruction

[Jason Schoon]

Especially given that we provide a configuration option for allocating in 
either .bss, heap, or stack (although I'm not sure how well it has been 
followed), I would think we wouldn't want to start blindly allocating on the 
stack. I have been on many embedded systems with 2k or smaller stacks. They 
are a pain all around, but it seems as though Busybox has at least made a 
partial attempt to address this.

I agree the cleanup is a mess though. atexit() is a great idea for the most 
part, although as you said, it is not immediate reclaming of space. If 
somebody cares at all about this cleanup stuff, rather than just letting the 
memory be return automatically, they probably want it returned as soon as 
possible.

Ugh. Memory limitations are a pain.

On 8/29/05, Rob Landley <rob at landley.net> wrote:
> 
> 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
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/cgi-bin/mailman/listinfo/busybox
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.busybox.net/pipermail/busybox/attachments/20050829/b6fd723c/attachment.htm