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

Discussion in 'Ruby' started by Daniel Berger, Dec 14, 2004.

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

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


    - Dan
    Daniel Berger, Dec 14, 2004
    1. Advertisements

  2. Daniel Berger

    Nick Guest

    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, Dec 14, 2004
    1. Advertisements

  3. Daniel Berger

    nobu.nokada Guest


    At Tue, 14 Dec 2004 21:44:08 +0900,
    Nick wrote in [ruby-talk:123582]:
    Not at all. GC occurred in another thread causes a crash
    nobu.nokada, Dec 14, 2004
  4. Daniel Berger

    Nick Guest

    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, Dec 14, 2004
  5. 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
    Wayne Vucenic, Dec 15, 2004
  6. 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

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


    Daniel Berger, Dec 16, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.