Ruby

=begin

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 report it.

In addition, the fact that native threads use the same class name is also confusing.
It means that code that would work on fully GIL encumbered green threads would work fine
but may break in mysterious ways using native threads.

Finally, there is the fact that any code that could possibly be called from
a native thread now has to be thread safe, making writing C extensions difficult.

These two are wrong.
Ruby 1.9 uses native threads but still use GIL just because of the problem you pointing out.
=end

=begin

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 report it.

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

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

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.

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

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.
=end

=begin
Hi,

2009/12/21 Christian Holtje [email protected]:

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 report it.

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 [email protected]

=end