Hi all,

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>
>> wrote:
>> > ..[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
>> you

> 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?


UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to