From: BCoish@... (Brad)
Date: 2003-11-28T00:02:10+09:00
Subject: Re: Ruby thread problems

ts <decoux@moulon.inra.fr> wrote in message news:<200311271014.hARAEWa21421@moulon.inra.fr>...
> >>>>> "B" == Brad  <BCoish@Dymaxion.ca> writes:
> 
> B> Q: Doesn't the setjmp/longjmp maintain the stack information?  Seems to me that
> B>    setjmp/longjmp would be quite unusable if it didn't maintain stack 
> B>    information.
> 
>  longjmp restore the stack registers (%esp on 80x86), not the stack content.
>  Say another way, this is valid in C
> 
>     int g()
>     {
>         longjmp(jmp, val);
>     }
> 
>     int f()
>     {
>         setjmp(jmp);
>         g();
>     }
> 
>  but this don't work
> 
>     int g()
>     {
>         setjmp(jmp);
>     }
> 
>     int f()
>     {
>         g();
>         longjmp(jmp, val);
>     }
> 
> 
> 
> B> Perhaps this is a naive assumption on my part as I have not had opportunity to
> B> use setjmp/longjmp before now.
> 
>  When a thread is stopped, ruby store the content of the stack in stk_ptr,
>  when it want to resume a thread it must restore the stack pointers before
>  calling longjmp()
> 
> 
> Guy Decoux


Mr. Decoux,

Thank you again for your speedy response.  I now feel I have a better 
understanding of what's going on during the thread context switch/restore.  
My problem was, I didn't get that setjmp/longjmp only maintained stack 
addresses and not content.  And that the content had to be manually restored.

The problem, as it turns out, can be easily fixed by adding the following 
define to the build procedure: 

   __FAST_SETJMP

This tells the compiler to use the Alpha OpenVMS system specific version of 
setjmp/longjmp rather than the CRTL version.

Regards,
Brad