A Simple Matter of Programming

If you have two Ruby thread that are making calls to standard out at the same time, they will be interleaved. Try it:

Thread.new {puts 1, 2, 3}; puts 1, 2, 3

Now, if you happen to have some other native thread out there, and it happens to be calling CoreAudio APIs, and the main Ruby thread happens to print more things than the other Ruby thread, the other native thread inexplicably gets into an infinite loop and pegs the CPU.

I kid you not.

It dies peacefully if the main Ruby thread finishes. Otherwise it requires a force quit. If the secondary Ruby thread prints more than the main thread, it has no effect. And it is clearly the number of objects printed, not the amount of data.

In some cases, the behavior will wait until after a gets, if there is one. This seems to depend on how many Ruby threads there are, and sometimes on whether there is a second gets (which is, of course, impossible).

It seems like there’s a race condition on access to standard out, but I can’t imagine what CoreAudio has to do with it. CoreMidi APIs have no effect. And it doesn’t have any business touching standard out. It may have something to do with thread scheduling, and the fact that the CoreAudio calls access the high speed timer. But CoreAudio could be a red herring.

Any help?