I've released the highly experimental first version of win32-thread.
This code is ultra-alpha, and has already been banned in 37 countries.
Oh, but not yours.
What is it?
···
===========
A probably-naive attempt to wrap native Win32 threads for Ruby.
It only works for simple cases. Attempting to create more than one
native thread causes application errors and/or segfaults. Not too
useful at the moment, but barrels of fun. Good at parties.
So why did you put it out?
For kicks mainly, and for brave folks to tinker with. I'm also hoping
someone out there smarter than me might take a look and find a way to
make it better.
Fascinating... Is ruby native thread-friendly? Without the ability to keep multiple interpreter contexts, I would think this would cause the interpreter to go crazy. ("No thread context and no beer make Ruby go something something...").
Nick
Daniel Berger wrote:
···
Hi all,
I've released the highly experimental first version of win32-thread.
This code is ultra-alpha, and has already been banned in 37 countries.
Oh, but not yours.
What is it?
A probably-naive attempt to wrap native Win32 threads for Ruby.
It only works for simple cases. Attempting to create more than one
native thread causes application errors and/or segfaults. Not too
useful at the moment, but barrels of fun. Good at parties.
So why did you put it out?
For kicks mainly, and for brave folks to tinker with. I'm also hoping
someone out there smarter than me might take a look and find a way to
make it better.
At Tue, 14 Dec 2004 21:44:08 +0900,
Nick wrote in [ruby-talk:123582]:
Fascinating... Is ruby native thread-friendly? Without the ability to
keep multiple interpreter contexts, I would think this would cause the
interpreter to go crazy. ("No thread context and no beer make Ruby go
something something...").
Not at all. GC occurred in another thread causes a crash
immediately.
Thats what I thought. Does anybody know if there any intention to create "thread-context" structures so the interpreter can run in multiple thread contexts in a future ruby version?
Nick
···
nobu.nokada@softhome.net wrote:
Not at all. GC occurred in another thread causes a crash
immediately.
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
···
<nobu.nokada@softhome.net> wrote:
Not at all. GC occurred in another thread causes a crash
immediately.
