On 10 May 2015 at 13:57, Ben Coman <btc@openinworld.com> wrote:
not that output is interleaved with a specific policy.
Hi Eliot,
I guess it was hard to analyse that output dump from your phone, and I should have been more explicit. The problem is not the interleave order, but duplicate and missing output items. I've cut down the example and and manually reordered the Squeak items to make it easier to see this.
Transcript clear. [ $a asciiValue to: $h asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' '. Processor yield. ]. ] forkAt: 40. ]. ] forkAt: 41.
Squeak 4.5 gives... $a1 $b1 $b1 $c1 $d1 $e1 $f1 $g1 $h1 $a2 $b2 $b2 $c2 $d2 $e2 $f2 $g2 $h2 $a3 $b3 $b3 $c3 $d3 $b4 $d4 $f4 $g4 $g4 $b5 $c5 $d5 $d5 $f5 $a6 $a6 $c6 $d6 $e6 $f6 $g6 $h6 $a7 $b7 $d7 $d7 $g7 $h7 $f7 $a8 $a8 $b8 $c8 $c8 $f8 $g8 $h8 $h8 $b9 $b9 $c9 $e9 $e9 $f9 $f9 $g9 $h9
Pharo 50041 gives... $a1 $b1 $c1 $d1 $e1 $f1 $g1 $h1 $a2 $b2 $c2 $d2 $e2 $f2 $g2 $h2 $a3 $b3 $c3 $d3 $e3 $f3 $g3 $h3 $a4 $b4 $c4 $d4 $e4 $f4 $g4 $h4 $a5 $b5 $c5 $d5 $e5 $f5 $g5 $h5 $a6 $b6 $c6 $d6 $e6 $f6 $g6 $h6 $a7 $b7 $c7 $d7 $e7 $f7 $g7 $h7 $a8 $b8 $c8 $d8 $e8 $f8 $g8 $h8 $a9 $b9 $c9 $d9 $e9 $f9 $g9 $h9
The Pharo output is untouched (except to insert newlines). Its ordering is only a side effect of correct behaviour wrt showing *all* output *once only*. Indeed its only a side effect that the output ordering (presumably) reflects the actual order that processes were scheduled -- but actually this is a critical advantage when trying to debug multi-threaded race conditions.
cheers -ben
On Sun, May 10, 2015 at 12:20 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Ben,
first, thanks for responding dispassionately to the technical issues.
As far as thread-safety I thought the issue with the transcript was not providing some form of protection against unpredictable interleavings of output from multiple separate processes, but was just avoiding lock-up. If one outputs to another kind of stream (file, terminal window) from multiple processes you typically get jumbled output on a first-come first-served basis. What one wants IMO is that the transcript remains robust, with no red morphs of death, not that output is interleaved with a specific policy.
How you gonna ensure that, when only tool that you have is a completely single-minded (err.. threaded :) ) / thread unsafe Morphic in your hands, that is absolutely dangerous to use outside UI thread and recipe for disaster when fiddling with its state or interrupting it at non-safe point? Red morphs of death is actually a good sign of that, that Morphic has little to offer to those, who dare to use multiple threads. Sometimes i thinking, would it be better to throw away all that multi-threading crafts in VM and image, and make smalltalk *way more* simpler and straight (like many other interpreted languages, that don't have threads).. Because bulk majority 99.999% of our codebase never using/deals with threading anyways. Besides, most of the people finding multi-threading bizarre and confusing.. So, lets just throw it away, no big loss. :) P.S. and i didn't meant to sound passionate, but rather sarcastic :)
Eliot (phone)
-- Best regards, Igor Stasenko.