art's abode

Here’s a document I ran across today which details some of the specific differences in the two languages. Just one of the many glorious tidbits:

Boo uses CLR threads, which generally map one-to-one to kernel threads and therefore exploit multiple processors and are fully preemptive.

In contrast, Ruby uses lightweight threads – threads implemented within the interpreter. Because of their extremely low switching latency, they can be used in situations where kernel threads impose too much overhead…[b]ut Ruby’s threads are limited to one CPU, and block on OS calls.

Microthreads can be implemented in user libraries, but only cooperative threads (as far as I know). I don’t know how important preemptive (within the hosted language) microthreads are. But the CLI (and therefore, Boo) seem to have no standard library implementation of lightweight threads.

All this is specific to the main Ruby implementation. JRuby, like Boo, relies on the underlying VM’s threading model – the JVM’s, in this case – and so its threads are generally fully preemptive and exploit multiple CPUs.

At the end of the day, I suppose comparing boo with ruby is a bit like comparing dicks to pussies, as ruby is an interpreted language through-and-through, whilst boo can be run, for instance using booi in interpreter mode, or using booc compile CLI bytecode binaries (which are absolutely tiny compared with, for instance, ruby2exe’ing a ruby project) to be run with mono/.NET or other CLR.

Also gotta love the mention of the JRuby: now we’re talking optimized best-of-breed solution. Lulz.

It’s pretty easy to handle signals in Ruby, which is sometimes necessary when you want your code to interact with the system running it.

Signalz Ahoy!

If you want to know which kill signals you have:

bash-3.2$ kill -l
1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
5) SIGTRAP      6) SIGABRT      7) SIGEMT       SIGFPE
9) SIGKILL     10) SIGBUS      11) SIGSEGV     12) SIGSYS
13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGURG
17) SIGSTOP     18) SIGTSTP     19) SIGCONT     20) SIGCHLD
21) SIGTTIN     22) SIGTTOU     23) SIGIO       24) SIGXCPU
25) SIGXFSZ     26) SIGVTALRM   27) SIGPROF     28) SIGWINCH
29) SIGINFO     30) SIGUSR1     31) SIGUSR2

If you want to know which kill signals Ruby recognises:

irb(main):002:0> Signal.list.keys.join ", "
=> "USR1, BUS, USR2, TERM, SEGV, KILL, EMT, EXIT, STOP, SYS, TRAP, INFO, IOT, HUP, INT, WINCH, XCPU, TTIN, CLD, TSTP, FPE, IO, TTOU, PROF, CHLD, CONT, PIPE, ABRT, VTALRM, QUIT, ILL, XFSZ, URG, ALRM"
irb(main):003:0>

Some quick-n-dirty source code:

There’s probably better ways of doing this, but here’s a stupid little example demonstrating how it could work:

bash-3.2$ cat signal.rb

$hups = 0

def quit_on_int
  puts "Quitting on interrupt signal."
  exit
end

def quit_on_quit
  puts "U sure killed me guud!"
  exit
end

def handle_hup
  $hups=$hups+1
  puts "HUP! (count: #{$hups})"
end

while true
  trap("INT") {quit_on_int}
  trap("HUP") {handle_hup}
  trap("QUIT") {quit_on_quit}
end

Example in use:

bash-3.2$ ruby signal.rb
HUP! (count: 1)
HUP! (count: 2)
HUP! (count: 3)
^CQuitting on interrupt signal.
bash-3.2$

We run the program as above, then send it three SIGHUPs (i.e., using "kill -HUP pid"). We break out the program using ^C (ctrl-c), sending an Interrupt. Note this may not work in windows.

bash-3.2$ ruby signal.rb
U sure killed me guud!
bash-3.2$

Here we run the program again, and send it a SIGQUIT ("kill -QUIT pid").

• RubyCLR, a ruby bridge to .NET:

A high-performance Ruby to .NET bridge that allows seamless integration of CLR and Ruby objects in the same Win32 process. Use it to create rich client applications using the Windows Forms or Windows Presentation Foundation libraries.

• John Lam (the RubyCLR developer) discusses DLR, ruby and Silverlight.

• An insightful video on mashing up Silverlight (using the Dynamic Language Runtime) and ruby, together with Python, VB and JavaScript:

Presented by Jim Hugunin, John Lam
Duration: 72 minutes, 26 seconds