From: BCoish@... (Brad)
Date: 2003-11-27T03:07:12+09:00
Subject: Re: Ruby thread problems

ts <decoux@moulon.inra.fr> wrote in message news:<rfcn0b8dy80.fsf@moulon.inra.fr>...
> >>>>> "B" == Brad  <BCoish@Dymaxion.com> writes:
> 
> B> Using ruby 1.8.0 Preview 5 (Porting ruby to OpenVMS Alpha)
> 
>  perhaps best if you use 1.8.1 (if you can)
> 
> B> Q: (a) What is the intent of this routine?
> B> (b) Why does this routine call rb_thread_restore_context?
> 
>  Like the name say it : to extend the stack :-)
> 
>  Imagine that a thread was stopped with 0xe000000 for the stack pointer
>  (th->stk_pos)
> 
>  When ruby restore the context of this thread, the thread must be restarted
>  with a valid stack pointer. To do this it compare the actual stack value (&v)
>  with the saved value (th->stk_pos).
> 
>  For example, if I'm on a system where the stack grow downward, and ruby find
> 
>    &v == 0xf0000000
>    th->stk_pos = 0xe0000000
> 
>  ruby must put elements on the stack until it have (&v <= th->stk_pos). At
>  this step it can restore the thread.
> 
>  To do this rb_thread_restore_context() call stack_extend(). stack_extend()
>  store 1024 VALUE on the stack (this is the declaration VALUE space[1024];)
>  to decrease the stack pointer, and it call recursively
>  rb_thread_restore_context() until it find (&v <= th->stk_pos)

Thanks for the speedy reply, sorry took so long to get back to you.  I've 
updated to using ruby 1.8.1 preview 2; However, the problem continues to
persist.

Q: Doesn't the setjmp/longjmp maintain the stack information?  Seems to me that
   setjmp/longjmp would be quite unusable if it didn't maintain stack 
   information.

Perhaps this is a naive assumption on my part as I have not had opportunity to
use setjmp/longjmp before now.