Hi,

At Sun, 27 May 2007 10:07:36 +0900,
gga wrote in [ruby-core:11264]:
> > The point of this problem is that ruby interpreter is not
> > thread-safe as a library, so that you must not call it in
> > native-threads other than the native-thread on which ruby
> > itself is running.  Instead, you have to send any requests to
> > the native-thread and process them in it.
> 
> But like I said, I'm not using it in a non-thread safe way.
> Only a single ruby thread keeps running ruby code at a time.

You can't call ruby code in multiple threads at any time.

> This should be equivalent to having a global lock and running
> eval("sth") each time.

Perdon, what's "sth"?

> 
> Whether the thread_id for it is 0, 1, 2, etc. should not be relevant.
> Or is there anything in the ruby code that makes this impossible?  It
> seems only the GC is constrained by needing info about the stack.  But
> resetting the stack on each iteration should (mostly) address this.

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.

> There's still the rare possibility of some temporary VALUEs on the stack
> of the main thread being collected when the new thread with the new
> stack beginning runs, but this should be rather rare (I can only think
> this can happen if an extension invokes a new thread which in turn calls
> some other extension).

That is the good enough reason.

> Any static or global variables should be fine by being invoked in
> different threads.

Yes, they are not concerned with stack.

> > It does know about the native-threads which are created in
> > ruby.  Therefore, you can't store VALUEs on the stacks of other
> > threads.
> > 
> 
> Ouch.  This sounds much worse than 1.8.

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?

Crash.

> > [patch attached...]
> 
> What's this?  This is not my patch (have not sent it yet -- or written
> it, for that matter).

It's a patch I wrote, to merge Init_stack and ruby_init_stack,
not yours.

-- 
Nobu Nakada