Re: [ ruby-Bugs-11134 ] Init_stack and ruby_init_stack fail toreinitstack(threadsproblem?)

Nobuyoshi Nakada wrote:
> Hi,
> 
> 
>> This should be equivalent to having a global lock and running
>> eval("sth") each time.
> 
> Perdon, what's "sth"?

As I proposed, any ruby code not involving another extension.  But,
ideally, it should be any ruby code.

> 
> If it were reset, VALUEs on other threads won't be marked anymore.
> And the thread mechanism of 1.8 or former works by overwriting
> machine stack, so stack address must not change.
> That is the good enough reason.
> 

Okay.  But I can have a function travel the current stack, register the
(potential) VALUE addresses found there in a global hash for example,
and then safely change the stack address.
After my callback finishes, clear the hash and revert the stack pointer
to its old value.  That should be thread safe for 1.8.  Right now, the
lack of a way to reset the stack safely prevents me doing this.
That is, I'd like the api to behave like:

rb_push_stack();
INIT_STACK();
// call new code in this thread (or in this branch of an embedded ruby)
rb_pop_stack();

Under YARV, I'd hope that book-keeping to be done for me automatically
as it switches from thread to thread (but embedded rubys may still need
to do the book-keeping manually).

Other than that, the only way to solve the issue without breaking
backwards compatibility with previous C extension code, would be to have
VALUE be an actual C++ class, whose contructor/destructor
registers/unregisters itself with the interpreter.  For swig SVN head, I
added a class called GC_VALUE to support the STL containers that does
just that and works peachy.
Obviously, that makes ruby a C++ api, which I understand Matz does not want.

>>> It does know about the native-threads which are created in
>>> ruby.  Therefore, you can't store VALUEs on the stacks of other
>>> threads.
> 
> No, the restriction is applied to 1.8 too.
>
>> How do any C extensions work at
>> all on a ruby thread other than the main ruby thread?
>>>
>> Ouch.  This sounds much worse than 1.8.
> 
> Crash.
> 

Hmm... isn't native threads the default for yarv?  If so, that's
definitively not the same for 1.8.  Currently:

Thread.new { // do something with a dso }

will not crash the interpreter.  You don't get true multithreading, but
not a crash.

-- 
Gonzalo Garramu
[e-mail]

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy