Alexander Burger <a...@software-lab.de> writes:
> On Tue, May 13, 2014 at 10:57:45PM +0300, Rowan Thorpe wrote:
>> On 13 May 2014 21:46, Jorge Acereda Maciá <jacer...@gmail.com>
>> > ..[snip]..
>> > Am I missing something? alloca() just adds an offset to the stack
>> > pointer:
see "man alloca(3)"
>> Q&A which has great answers and comments, many defending alloca(),
>> most however explaining why it (and VLAs) are apparently a bad idea
>> for anything other than guaranteed *small* chunks:
>> One comment caused me to eventually stumble on Memory Pools:
>> which seems like it might be one of the best compromises for what
> self-made memory pool might be more efficient than malloc(), because
> it can be less general and thus simpler (as the PicoLisp 'gc'), but it
> won't decrease the total memory usage (heap + stack), and involves
> more overhead than the hardware stack mechanisms.
Another argument against using custom memory allocators could be found
in the case of the recent openssl Heartbleed bug.
> PS. Having said all this about "unlimitedness", in PicoLisp it is
> broken as soon as coroutines are used. A single coroutine is limited
> in stack size (but in turn there may be an unlimited number of
> coroutines, again needing an unlimited stack).
When the first coroutine is started, does it affect the original stack
size and limit? Or is the first/main "coroutine" always without the
stack restriction? What I initially use a lot of stack and then create
a coroutine? Are the coroutine stacks allocated on the hardware stack
too? In that case, how are coroutines garbage collected?