On 10 May 2015 at 13:57, Ben Coman <[email protected]> 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 <[email protected]> > 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.
