I’m staggered by the enormous discrepancy in news coverage here, with the media still eulogizing Steve Jobs after a week and a half, Dennis Ritchie passes away, and receives hardly a blip.

How can this be? The man was a giant in the field. He was one of the inventors of C, which became the most successful programming language, remains extremely popular after four decades, and was a direct ancestor to many of the most used languages of the present day. It’s difficult to overstate its impact; nearly all of the software you encounter today — on PCs, on servers, in embedded systems, or anywhere — was written in C or a language that traces back to C. It was Ritchie who decided on one of the keys to C’s success, its “portable assembly” aspect: It had to let you get close to the metal, while still abstracting away the architecture’s particulars. Another aspect to C’s success was its excellent manual written by Ritchie and Brian Kernighan, commonly called simply “K&R”: short, clear, and comprehensive; information rich yet simple writing; it set a standard that few computer texts come close to reaching.

He was a father of Unix, which has led to more of today’s operating systems than you can shake a stick at. The first great wave of webservers was on Solaris and other System V variants. There’s a BSD Unix sitting inside MacOSX and iPhoneOS. Richard Stallman modeled his GNU project on Unix, and Linus Torvalds’ Linux kernel was a clone of Unix’s — and the second great wave of webservers was build on these. Nearly all of the servers you encounter online run operating systems using Ritchie’s designs. And every Android smartphone as well. How is it that one OS family can span such a range? It was Ritchie who pushed for Unix to be rewritten to have a portable core for the bulk of the OS, with the hardware-specific bits isolated away for easy migration to new machines. No operating system had ever done this; it let Unix escape the PDP, and escape it did.

News media be damned. I feel Ritchie’s passing much more keenly than Jobs’. He wasn’t showy, but his influence was legion.

Java NIO’s Selector class is surprisingly difficult to use with multiple threads. Everyone that tries it encounters mysterious blocking, much of which is due to it sharing a lock with SelectableChannel.register. So, if you happen to try to register a channel in a thread other than the selector thread, it blocks that thread until the select is done. Boo.

So, this is a NIO rite of passage of sorts, finding this misfeature and then looking up how to work around it. The usual answer is to keep a ConcurrentQueue of pending registrations, and have your select loop process that queue between select calls. Uggggleeee. It occurred to me that using a synchronization lock, we can do better.

To register a channel and get the SelectionKey:

  synchronized(registerLock) {
      selector.wakeup();
      key = channel.register(selector, operations, attachment);
  }

And in the select loop:

  // before
  synchronized(registerLock) {}
  // between
  numEvents = selector.select(timeout);
  // after

If the loop is before or after when our registration block takes the registerLock, we’re fine, as having the registerLock prevents the loop from reaching select until we’ve registered and released the lock. If the loop is inside select(), then the wakeup() will cause it to exit select, and it won’t re-enter because we hold the registerLock, so we’re fine.

The tricky case is when the loop has the registerLock or is between releasing the registerLock and entering select(). In these cases, the registration block takes the registerLock and races with the loop over select() and wakeup(). Fortunately, the NIO designers anticipated that programmers would have a desire to ensure a Selector wasn’t selecting, even if the wakeup was called in the window between checking it was okay to enter select and actually entering it. Selector.select() returns immediately if wakeup() had been called after that Selector’s prior select(). So, our race doesn’t matter, the select() always exits, and we’re safe.

This is so much simpler than building up a queue of registrations and processing them in the select loop, and we get the SelectionKey right away, I wonder if I’m missing something. Why is the textbook technique to use a ConcurrentQueue, instead of a synchronization lock like this?

Time to take a break from my break from blogging.
Today I found this video pretty interesting, a neuroscientist discovers his brain scan matches those of psychopaths.

[Update: link “http://wsf.tv/videos/embedded/1361” has died, sorry.]

I switched to OpenSuSE tonight.
PCLinuxOS had been grating on me for the last few months, since they decided to drop most of their man pages in favor of entering “man foo” into Google. But after an ordinary update, tonight I discovered that the new kernel hung on boot. To my distress, GRUB didn’t list any previous kernels when I intercepted its autoboot. After trying and failing to get grub to show me any files on the filesystem so I could select another kernel from /boot to boot from (why is this so hard?), I booted from a rescue disk… and discovered that there was only one kernel version in /boot, PCLinuxOS had been deleting the previous versions. This bad practice dismayed me, it’s standard for distributions to keep the previous one or two kernels around, in case of a case like this, where a kernel that doesn’t boot on someone’s hardware get pushed.
I’d been meaning to try out SuSE again for a while, and this pushed me over. I backed up my disk and did a clean install.
We’ll see how the new distribution goes.

When I read about someone putting the pin in a dropped grenade, I think “Why is he doing that? He’s going to die! No, this didn’t happen, it’s just made up by a hack who doesn’t know how grenades work.” Congratulations, you just destroyed the immersion in your story. Similarly for a grenade exploding while still held pending the throw, or a thrown grenade with the spoon still against it (for graphical media).

No need to trek through the snow to the library, research is now as simple as visiting http://en.wikipedia.org/wiki/Hand_grenade from the comfort of home, yet curiously, this seems to be a disease of newer works, despite older works having hand grenades in their stories if anything more often.

So, evidently there’s a need for a primer for writers. Here goes:
Anatomy of a hand grenade: The body of a grenade is a shell containing explosives and a timed fuze. Against the shell is a lever called the spoon, which is connected to a spring-loaded trigger called the striker, which starts the fuze. A safety pin holds the spoon in place.
Operation: Hold the grenade in your throwing arm, pressing the spoon against the body. Pull the pin. Throw the grenade at the enemy. With the pin removed, the spring will now push the spoon away and the striker starts the fuze, which in a short time will detonate the explosive.

Note that the fuze can’t be stopped, and it’s the spoon which triggers the grenade, not the pin. So a held grenade can be re-safed by replacing the pin, which might be the seed of the myth that the pin will deactivate a cooking grenade.

This dusk, some of the Pasadena peahens decided to go scampering around above my and my neighbors’ ceilings. They’re pretty large birds, so I could hear them up there clearly!

Daniel Huffman has produced some interesting maps of the US’s major river systems, done in the style of intracity rail line maps. I especially like the one of the Columbia’s system.
He talks about generating these river maps here.
Naturally, he has other interesting things to say about maps, such as a discussion on projection conformality.

Accidentally compare a character and an integer.
$ python -c 'print "\0" > 1024'
True

Wait, what? Any character is larger than any integer? Why are chars and ints intercomparable then? Shouldn’t I get either a type error or a meaningful comparison? This seems like it’s guaranteed to be wrong!

So, I just upgraded Easy Peasy on my Eee. And surprise, surprise, it broke WiFi again.
Fortunately, there’s a user-contributed fix available, like the other times this has happened!
Unfortunately, the maintainers aren’t adopting it, also just like the other times!

This is a distribution targeting one specific line of netbooks, and in every version of it, WiFi doesn’t work. Scrapheap time for Easy Peasy.

When the New York airports re-opened following the recent blizzard, there was a backlog of flights, and short-staffed airline terminal support personnel couldn’t process them as fast as they arrived. Which planes do you think got serviced, and which delayed on the tarmac for hour after hour?

It’s no surprise if you know that the rule put into effect after repeated and persistent multi-hour tarmac delays by the airlines applies only to domestic flights. Miraculously, just enough personnel were found to keep the domestic flights coming to the gates without hitting the delay lengths which would trigger fines — but not enough to service the international flights, for which there are no tarmac delay penalties.

And that’s why the flight from Vancouver, BC to Kennedy Airport sat on the tarmac for over 12 hours. Airlines had no incentive to service it, but did have an incentive to prioritize domestic flights over it. Corporations don’t feel shame or guilt for bad behavior, but they do feel the sting of fines and act to avoid them. We need to choose our incentives carefully.