From: Matthew Bloch <mattbee@...>
Date: 2002-05-23T19:21:48+09:00
Subject: Threading oddness

Consider this fragment:

      v = get_event
      case v
       ...
        when LoginEvent
          print "login event for #{v.username} #{v.password}\n"
          $att.login_state(1)
          a = Thread.new {
            print "trying login\n"
            if $clientshell.login(v.username, v.password) # DRb call
              $att.login_state(2)
              print "login successful\n"
            else
              $att.add_child(FleetingText.new("Invalid login", 500))
              $att.login_state(0)
              print "login failed\n"
            end
          }
          print "login thread = #{a} / all = #{Thread.list.join(' ')}\n"

My problem is that this login event can happen more than once, but the 
second time it happens, I never see 'trying login' -- the thread seems to 
just be ignored.  The print statement at the end shows a fifth thread 
present the first time around, but only four threads the second time, i.e.

   [fx: logs in]
login event for test test
login trying...
a = #<Thread:0x40824f14> / threads = #<Thread:0x40824f14> 
#<Thread:0x4081c940> #<Thread:0x4081ca58> #<Thread:0x4081cdb4> 
#<Thread:0x404475c8>
login failed

   [fx: logs in again]
login event for test test
login trying...
a = #<Thread:0x407e8730> / threads = #<Thread:0x4081c940> 
#<Thread:0x4081ca58> #<Thread:0x4081cdb4> #<Thread:0x404475c8>

   [fx: bangs head against wall]

So the second time, despite being having a valid object reference, the 
login thread doesn't seem to be linked to Ruby's list of threads to run.  
If I explcitly call a.run before the final print statement, the new thread 
is never listed or run.

The only extenuating circumstance I could think of was that I'm using SDL 
as an extension library which uses setitimer, as Ruby does for thread 
scheduling, but peering closer, Ruby only uses the virtual itimer, and SDL 
only the 'wall time' itimer, so there's no conflict.

Any ideas?

-- 
Matthew