Using ruby 1.8.0 Preview 5 (Porting ruby to OpenVMS Alpha)
perhaps best if you use 1.8.1 (if you can)
Q: (a) What is the intent of this routine?
(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.
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.
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);
}
Perhaps this is a naive assumption on my part as I have not had opportunity to
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()
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.
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);
}
Perhaps this is a naive assumption on my part as I have not had opportunity to
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.
