Hi,

2009/12/21 Christian Holtje <redmine / ruby-lang.org>:
> Issue #2505 has been updated by Christian Holtje.
>
>
>> > Some examples:
>> >  priority doesn't do the same thing on Solaris than Linux.
>> >  loop{} will lock the process up in Solaris, but not Linux.
>>
>> They may true.  If a difference cause a practical problem, please reportt.
>
> http://redmine.ruby-lang.org/issues/show/1169 - priority

It is duplicated not only in Solaris but also in Linux.  It is
difficult to support thread priority.  IMO, we should think that
Thread#priority= is already deprecated.


> http://redmine.ruby-lang.org/issues/show/2359 - loop{}

Not duplicated.


> These are just two examples.  Threading across platforms is very different.  Heck, some platforms have multiple versions of threads.

You are right.  Could you please report individually?


>> These two are wrong.
>> Ruby 1.9 uses native threads but still use GIL just because of the problem you pointing out.
>
> I know that the GIL is still being used, but this still doesn't protect data-structures that aren't ready for native threads.  A C extension can still be thread-unsafe and fail in hard to understand and debug ways.

I cannot get your point.  GIL locks not only code of Ruby but also
code of C extension.  IWO, an execution of code in C extension is
not interrupted (unless you use BLOCKING_REGION or create new thread
explicitly).  Even so, it can be thread-unsafe so easily?


> Having a new class that uses the native threads without the GIL everyplace would have been a better solution than potentially breaking.

It might be something that is currently developped, called MVM.


> Or using something that is completely data safe, like using erlang style message passing with processes, would be even better and more platform independent; C extensions wouldn't have to worry about being thread safe and locks wouldn't be needed for passing information around.

It is not Ruby :-(

-- 
Yusuke ENDOH <mame / tsg.ne.jp>