Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > [ANN] win32-thread 0.0.1 (or, do you feel lucky?)

Reply
Thread Tools

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

 
 
Daniel Berger
Guest
Posts: n/a
 
      12-14-2004
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

 
Reply With Quote
 
 
 
 
Nick
Guest
Posts: n/a
 
      12-14-2004

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




 
Reply With Quote
 
 
 
 
nobu.nokada@softhome.net
Guest
Posts: n/a
 
      12-14-2004
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.

--
Nobu Nakada


 
Reply With Quote
 
Nick
Guest
Posts: n/a
 
      12-14-2004
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> 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


 
Reply With Quote
 
Wayne Vucenic
Guest
Posts: n/a
 
      12-15-2004
<(E-Mail Removed)> wrote:
> 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


 
Reply With Quote
 
Daniel Berger
Guest
Posts: n/a
 
      12-16-2004
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What do you use java for ? AndDoes Java make you feel happy? zelzel.zsu@gmail.com Java 15 11-12-2005 03:54 AM
want to search for anyone in the world? Feel curious to know who might be searching for you? nightelves6667@yahoo.com Cisco 0 03-27-2005 06:07 PM
Tell Europeans how you feel F*ck You T-shirt Computer Support 1 03-04-2004 01:23 AM
Tell Europeans how you feel F*ck You T-shirt Computer Support 4 03-03-2004 11:12 AM
Tell Europeans how you feel F*ck You T-shirt Computer Support 1 03-03-2004 10:36 AM



Advertisments