Aaaand here why that mattered!  Also, did you know, you get dramatically different parallelism behaviors from the `go` keyword when you actually have more than one OS thread?  Yeah!  It's grrrrreat!
Aaaand here why that mattered!  Also, did you know, you get dramatically different parallelism behaviors from the `go` keyword when you actually have more than one OS thread?  Yeah!  It's grrrrreat!

... But no, seriously.  Without explicitly setting use of more than one core, the previous state of this test file appears to *always* pass.  Not "usually".  Always.  On go1.4, anyway.  I'm guessing this is because there's no syscalls or other scheduler-triggering points in the critical zone; still, quite remarkable and a bit of a shock.

Signed-off-by: Eric Myhre <2346ad27d7568ba9896f1b7da6b5991251debdf2@exultant.us>

polydawn/go-sup,polydawn/go-sup