Hello,

At 17:22 22/04/2002 +0900, Yukihiro Matsumoto wrote:
>In message "Re: Threads creating threads creating threads..."
>     on 02/04/22, Jean-Hugues ROBERT <jean_hugues_robert / yahoo.com> writes:
>Does allocated jmp_buf with fixed sized stack reside over the main
>stack?  Like this?
>
>    --stack bottom--
>     |
>     | grows this way
>     V
>    --stack top--
>
>
>      the gap
>
>
>    --thread stack1--
>
>      fixed size
>
>    --stack top-- jump_buf points here
>    --thread stack2--
>
>      fixed size
>
>    --stack top-- jump_buf points here
>    --thread stack3--
>
>      fixed size
>
>    --stack top-- jump_buf points here
>
>Right?                                          matz.

Yes. You got it.

You can have "multiple" fixed sizes, with pools, etc...

The stack's size is "fixed" at creation (can not grow dynamically under MMU 
control) but you can grow it by "chaining" "stack-chunks" together using 
some explicit call_with_bigger_stack( size_t, (*continue)(), client_data).

This would be useful if most of the time the stack needs to be small but 
sometimes it needs to be big. Growing the stack before calling a function 
increases the cost of function calls however, but not a lot because most of 
the time you can reuse a free stack-chunk.

A C extension could tell about how much stack it needs (assuming a 
conservative big requirement, 32 Ko or more, if no explicit hint from the 
extension). When calling a C extension, you would have to either use the 
current stack or grow it temporaly.

Please note that some longjmp() implementation are destructive. i.e. you 
cannot re-use the same jmpbuf after longjmp(), you have to reinit it.

Hope this helps.

BTW: When I implemented a VM for an interpreted language of my own, I kind 
of never liked the way I handled threads using the native processor's 
stack. I felt like handling the stack should have been part of the VM 
instruction set (like it is in the Smalltask 80 VM I think). But I suspect 
it is more efficient to use the native stack, if not as elegant.

Yours,

Jean-Hugues