ruby & native threading

Stefano Zacchiroli said:

To balance this, according to my first read of Ruby’s threading capability, it’s my impression that not only at most one thread can execute Ruby code at a time (limitation shared by OCaml, due to the non-distributed nature of mark and sweep garbage collectors), but also a thread blocked on a syscall will block all other threads to run.

Dumb Ruby threads (but I still hope I’m wrong …)

This is not totally true:

  • Yes, Ruby threads are user-level: you won’t get speedup from dual-cores or dual-processors system. In python, this presentation claims (slide 39) that python threads are mapped to native threads, but that a giant lock always prevents the execution of more than one thread at a time (so library writers don’t have to write thread-safe code).
  • The ruby interpreter tries very hard to map blocking syscalls to their non-blocking counterparts (for example, all I/Os are passed to a select() call). This gets really dirty when you mix I/O and other syscalls. For example, see the strace output the following Ruby code:
    require 'thread'
    th1 = Thread::new do
      pid = fork { sleep 2 }
      Process::waitpid(pid)
      puts "Finished."
    end
    th2 = Thread::new do
      f = STDIN.read
      puts "Finished2."
    end
    th1.join
    
    select(1, [0], [], [], {0, 349})        = 0 (Timeout)
    gettimeofday({1168847486, 478832}, NULL) = 0
    select(1, [0], [], [], {0, 0})          = 0 (Timeout)
    waitpid(25249, 0xbf926810, WNOHANG)     = 0
    select(1, [0], [], [], {0, 0})          = 0 (Timeout)
    gettimeofday({1168847486, 479013}, NULL) = 0
    gettimeofday({1168847486, 479053}, NULL) = 0
    select(1, [0], [], [], {0, 59959})      = 0 (Timeout)
    gettimeofday({1168847486, 538971}, NULL) = 0
    select(1, [0], [], [], {0, 41})         = 0 (Timeout)
    gettimeofday({1168847486, 543017}, NULL) = 0
    select(1, [0], [], [], {0, 0})          = 0 (Timeout)
    waitpid(25249, 0xbf926810, WNOHANG)     = 0
    select(1, [0], [], [], {0, 0})          = 0 (Timeout)
    gettimeofday({1168847486, 543200}, NULL) = 0
    gettimeofday({1168847486, 543240}, NULL) = 0
    select(1, [0], [], [], {0, 59959})      = 0 (Timeout)
    gettimeofday({1168847486, 602842}, NULL) = 0
    select(1, [0], [], [], {0, 357})        = 0 (Timeout)
    gettimeofday({1168847486, 606842}, NULL) = 0
    select(1, [0], [], [], {0, 0})          = 0 (Timeout)

more efficient IRCing?

I need to reconsider my current way to do IRC.

  • My main computer is a laptop, so I can’t leave my IRC client open all the time.
  • More and more, I tend to ask stuff on IRC, then I have to leave, so I never get the chance to see the answer. Being able to stay connected all the time would be much easier.
  • I’m currently using XChat, and would like to continue using it (ie: I’d prefer to avoid going back to irssi).
  • Most of the time, I’m connected to two different networks (OFTC and Freenode).
  • I tried to set up an IRC bouncer, but I had the impression that it was complex, and not very user-friendly. (Maybe I’m wrong, or maybe I should have tried a different bouncer (which one?))
  • I’ve considered running two clients: XChat for my “main client”, and irssi just for logging everything. But that’s not really optimal.

Which solution are you using? Should I really go back to using irssi? Any good example irssi configs somewhere?

Update:

  • Comments are now open (they were closed because of a broken WP plugin)
  • I used to use screen+irssi, but then, I switched to xchat. I really like xchat, have written some custom scripts for it, and would prefer to continue to use it…
  • The possible suggestions I already got are:
    • use xchat with irssi_proxy
    • use xchat with ctrlproxy (looks very nice, but RC buggy and not in etch)
    • use xchat with shroudbnc (or psybnc, or dircproxy)

    Update 2:

    Ok, due to all the praise of the screen+irssi solution, I’ll give it another try…!