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.