<nobu.nokada / softhome.net> wrote:
> Not at all.  GC occurred in another thread causes a crash
> immediately.

Is GC the main problem with using native threads?

If so, some applications might be able to make do with a scheme where
the program alternates between two states:

State 1: GC gets disabled, and the native threads are allowed to run
State 2: All native threads (except the main Ruby thread) are
suspended, and GC.start is called

Of course, we need to avoid the situation where a native thread gets a
pointer to a ruby object but before it can dereference it, it loses
its time slice, then we switch to State 2, the GC moves the object, we
switch back to State 1, the thread does the dereference, and CRASH.

We could probably avoid this case by having the native threads call a
certain routine when they want to give up their time slice, and where
that routine is known not to dereference pointers to objects.

I appreciate that what I'm suggesting is a hack, but in part I'm
proposing it simply as a thought experiment to better understand the
issues involved with native threading in the current Ruby interpreter.
 Although if some application _really needed_ native threading,
tradeoffs like this might be acceptable.

Wayne Vucenic
No Bugs Software
Ruby and C++ Contract Programming in Silicon Valley
Agile Methods: Test Driven Development, Refactoring, Patterns