I was looking at threads.rb for Ruby 1.6, and I noticed that Mutex,
ConditionVariable (which uses Mutex), Queue, and SizedQueue explicitly
set Thread.critical to false when they’re done.
This causes interesting behavior:
require "thread"
m = Mutex.new
Thread.critical = true
m.lock
p Thread.critical #=> false
I think this wouldn’t happen if those functions either used
Thread.exclusive or were careful to restore Thread.critical to how it
was.
Alternatively, one could just use Mutexes for everything, is that
better? It might make for more efficient ports to native threads.
(BTW, will that ever happen? Should I care?)
···
–
Tom Felker
It might look like I’m standing motionless, but I’m actively waiting for
my
problems to go away.
In message “Mutexes end critical sections?” on 03/04/07, Tom Felker tcfelker@mtco.com writes:
I was looking at threads.rb for Ruby 1.6, and I noticed that Mutex,
ConditionVariable (which uses Mutex), Queue, and SizedQueue explicitly
set Thread.critical to false when they’re done.
I know. Thread.critical is for internal use. Don’t use it unless you
know what you’re doing.
what about the other question? Are there plans to move over to native
threads? I guess this would be a major change, but maybe someone has this
in the works…
robert
“Yukihiro Matsumoto” matz@ruby-lang.org schrieb im Newsbeitrag
news:1049684298.770648.14592.nullmailer@picachu.netlab.jp…
···
Hi,
In message “Mutexes end critical sections?” > on 03/04/07, Tom Felker tcfelker@mtco.com writes:
I was looking at threads.rb for Ruby 1.6, and I noticed that Mutex,
ConditionVariable (which uses Mutex), Queue, and SizedQueue explicitly
set Thread.critical to false when they’re done.
I know. Thread.critical is for internal use. Don’t use it unless you
know what you’re doing.
Seems matz said it’d be in Rite during RubyConf 2002. See [54881].
…
Q. Threading models. Will 2.0 will support plug-in threading models?
A. Rite will be native thread-safe [note: he means multiple isolated
interpreter contexts in the same process, via native threads], partially
using global locks, but user-level [aka green, or platform-neutral]
threads will remain. 2.0 will include native thread support as a
separate module (maybe called ‘nativethread’). Native threads by
default aren’t really good for Ruby.
…
···
On Mon, Apr 07, 2003 at 04:47:51PM +0900, Robert Klemme wrote:
Matz,
what about the other question? Are there plans to move over to native
threads? I guess this would be a major change, but maybe someone has this
in the works…
In message “Re: Mutexes end critical sections?” on 03/04/07, “Robert Klemme” bob.news@gmx.net writes:
what about the other question? Are there plans to move over to native
threads? I guess this would be a major change, but maybe someone has this
in the works…
Implementing Mutex, etc. with C? Perhaps. Somebody got to take the
role though. Shugo Maeda (the mod_ruby/eruby guy) once implemented
them long before. Maybe his implementation can be the starting point.
what about the other question? Are there plans to move over to native
threads? I guess this would be a major change, but maybe someone has this
in the works…
Implementing Mutex, etc. with C? Perhaps. Somebody got to take the
role though. Shugo Maeda (the mod_ruby/eruby guy) once implemented
them long before. Maybe his implementation can be the starting point.
Another place to look might be the boost C++ libraries[1], which
provide a platform-independent wrapping for OS-native threads,
mutexes, critical sections, etc…
(I realize the Ruby core doesn’t use C++, but I just guessed it
might be useful to see whatever approach they took with boost…)
