Good Work Indeed
Comic for March 31, 2009: Good Work Indeed
The same could be said for cookies, cheesecake, chocolate pies, and kittens.
Hey, that error message looks awfully familiar...
Oh, and are you curious about that memo Professor Donly is holding? You are? Then boy-howdy, today is your lucky day!
(Read beneath the fold to see what I mean.)
NOTICE!!!
TO TARGETING SYSTEM GROUP (ARNOLD, GÖT, ILANA, EVERETT, AND JENELLE)
(BUT ESPECIALLY JENELLE)
CHRONOS has been giving us a heck of a time recently. We put stuff in and it keeps shooting more stuff back out at us. Just yesterday Sasha tried putting Snootchums through the machine; 90 seconds later, out popped 367 clones. Adorable? Sure. But unacceptable.
We've pinpointed the problem: an update made to the targeting system code last week, revision 717. This was part of the major concurrency update that Jen and Arnold (but mostly Jen) have been working on for the past several months. The update was meant to speed up computation sufficiently so that we could dynamically calculate long trajectories - that is, so we could travel further than 100 seconds from the present without having to pre-compute the whole damn trip on AEON. We greatly appreciate their tireless efforts on this crucial aspect of the project; we'd appreciate it even more if the damn thing worked.
I've spent the last 13 hours staring at the code, and here is my determination:
[Editor's note: Lots of jargon in the next paragraph. The non-technically-minded in the crowd may just want to skip it. Heck, I'm a CS major and most of it is Greek to me. I'm pretty sure he's just saying that things are borked. -Greg]
Locking is currently implemented under the assumption of forward-flowing time. Unfortunately, this assumption breaks down upon activation of the machine. Certain threads of computation are mangled temporally. It becomes possible for a thread to obtain a locked lock by observing the state of the machine at an earlier point in time and retrieving the lock then.
Essentially, threads of code are getting into places they shouldn't be. This means certain loops are being executed endlessly until there's a buffer overrun somewhere. Or something like that. Dammit, Jen, I'm a physicist, not a computer scientist!
'But Dr. Donly!' I hear you ask. 'The clones! How do the clones figure into this?' Well, HOLD ONTO YOUR HORSES and I'll TELL YOU. Sheesh.
So: the end result of all Jen's crappy code is that our TTOs are being launched into what I'm dubbing 'Unfortunately Tight Loops'. Let's take Snootchums as an example. We zap him with the machine. The code goes haywire. Snootchums gets sent three microseconds into the past. Now (or rather, then) there are two Snootchumses. Three microseconds pass. Since multiple threads of computation all think they're running the show, the machine incorrectly decides to zap both of these Snootchumses three microseconds into the past. Now (i.e., then) there are four Snootchumses.
You can imagine how this goes, until finally the machine can't take any more and barfs all these Snootchumses out into the Continuum. God only knows where. For all we know there's a six-million-year-old menagerie of Snootchumses out there drifting silently through the Crab Nebula.
Why haven't we seen this problem before? Hell if I know. Is it because the new algorithm is of a much greater complexity than the old one? Maybe. Or MAYBE it's because - unlike the present update - the ORIGINAL code was written by someone MARGINALLY MORE COMPETENT than a HALF-DRUNKEN BABOON. You know what? That sounds about right to me. Yeah, let's go with that.
Anyway, the code has been reverted. It's going to stay that way until you people figure out a solution. You might want to think long and hard about this memo before you go on fiddling with the targeting system, okay?
O. R. Donly