Entrepreneurship: Life Long Learning

This week during our Ruby Hacking night, Bill Dolinar and I looked at Open3.popen3. I was disappointed that it didn’t seem to return a pid(process identifier) for the spawned process. The Ruby documentation shows that popen3 returns the three standard process io streams.

stdin, stdout, stderr = Open3.popen3('nroff -man')

It doesn’t return the pid of the process it’s spawning however. Which means you can’t wait on the child process with Process.waitpid. Looking at the Open3 source we see the following:

def popen3(*cmd)
pw = IO::pipe   # pipe[0] for read, pipe[1] for write
pr = IO::pipe
pe = IO::pipe

pid = fork{
# child
fork{ # .... CUT
# grandchild
exec(*cmd)
}
exit!(0)
}

Open3 does save off a pid but not the pid of the spawned ‘nroff -man’ process. Instead it captures the pid of a process which will spawn off the desired ‘nroff -man’ process. So why the double fork? Well Matz’s reasoning is so that the child process gets deamonized and reparented to the init process on unix. Maybe so, but that should be the programmers choice, whether to deamonize or not. Maybe I want to wait on the child process myself using Process.waitpid. Maybe I want to send the child process a signal, or kill it. All these tasks require that the programmer be provided with the pid of the child process.

First the double fork behavior should be selectable by the developer.

Second the pid of the spawned process should be returned.

The solution open4.rb

See also: RCR 206: Make popen3 raise an exception on failure

I’m a little sick of hearing the Ruby community tell everyone that performance doesn’t matter. Instead of trying to justify away poor performance or argue that a better algorithm will make up for Ruby’s shortcomings, a Ruby proponent should DO something about it.

I would like to see responses to criticism of Ruby performace such as this:
X is slow in Ruby, I’ve worked on it a little bit and it is now Y% faster.

Lets address the issue piece by piece and make it better instead of making ourselves look stupid by saying that performance isn’t important and everyone else has it wrong.

I’m thinking aloud about the whole Joel on Software discussion that Ruby is slow. We, as a Ruby Community, need to quit bashing general opinions and do something about it. If you don’t like the shootout, make it better or provide documentation that describes the language subsystems that benchmarks in the Great Computer Language Shootout are exercising.

As for my contribution, I’m working on Cardinal the Ruby implementation on top of Parrot. I enjoy working on Cardinal because I get to interact with implementors that are working on almost evey dynamic language imaginable. I see the tricks they use to improve performance and try to incorporate them into my work.

I would also encourage community members to try to submit more tests and patches to cleanup and improve Matz’s C implementation of Ruby. I’ve been able to submit a couple of small bug fixes and I’m recommiting myself to making a couple more submissions this week.

It’s time to stop heckling and start working. :)