[ANN] win32-thread 0.0.1 (or, do you feel lucky?)

[Daniel Berger]

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.

Where is it?
============
You can find in on the RAA or on the Win32Utils project page at
http://www.rubyforge.org/projects/win32utils.

What's wrong with it?
=====================
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.

Enjoy!

- Dan

 

[Nick]

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

 

[nobu.nokada]

Hi,

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.

 

[Nick]

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

 

[Wayne Vucenic]

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

 

[Daniel Berger]

I've tried tinkering with rb_gc_disable() and rb_gc_start() in various
places in the code but I haven't had any luck. I'm still getting
segfaults.

Feel free to join the win32utils-devel mailing list. I'd be happy to
hear any ideas you have.

Regards,

Dan