But wouldn't violate that the #forceUpdate preference when a non-UI process blocks the image for a while?

... "violate" is such a strong word. ^__^ I know that we have a "lock" in Transcript to at least not mix up the buffer contents. "forceUpdate" could be enabled by adding an extra semaphore to let the non-ui process sleep until that deferred UI message got processed.

Best,
Marcel

Am 25.01.2021 13:24:51 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:

In #endEntry, we could check for "Processor activeProcess == Project current uiProcess" to then use "Project current addDeferredUIMessage..." automatically.


But wouldn't violate that the #forceUpdate preference when a non-UI process blocks the image for a while?


Best,

Christoph


Von: Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 25. Januar 2021 12:25:56
An: squeak-dev
Betreff: Re: [squeak-dev] Transcript error when forceUpdate: false (?)
 
It's simply not thread-safe.

Hmm... in particular, there is a side effect (i.e. layout update) in the window's pluggable text morph. Even if #forceUpdate is false.

In #endEntry, we could check for "Processor activeProcess == Project current uiProcess" to then use "Project current addDeferredUIMessage..." automatically.

Best,
Marcel

Am 23.01.2021 21:05:05 schrieb Levente Uzonyi <leves@caesar.elte.hu>:

On Fri, 22 Jan 2021, tim Rowledge wrote:

>
>
>> On 2021-01-22, at 5:26 PM, David T. Lewis wrote:
>>
>> On Fri, Jan 22, 2021 at 02:03:10PM -0600, jaromir wrote:
>>> I ran the following in Squeak 5.3:
>>>
>>> TranscriptStream forceUpdate: false.
>>> [ 10000 timesRepeat: [ Transcript show: 'x' ] ] forkAt: 39
>>>
>>> When the Transcript window fills up, 'Message not understood' and 'Assertion
>>> failure' appear. I'm wondering is this a bug? Thanks. Jaromir
>>>
>>>
>>>
>>
>> It certainly does appear to be a bug.
>
> We had some discussion about it not so long ago; you can't use the Transcript to log bugs from Seaside very well, for example. Background processes, mutexs, that sort of thing. IIRC Levente offered an explanation?

It's simply not thread-safe.
If you want it to be thread-safe, you can pass your message to the UI
process to show it. Make sure your message is computed in its own process
and is passed as a precomputed string to avoid other kinds of race
conditions. E.g.:

| theMessage |
theMessage := 'Something very {1}.' format: { 'important' }.
Project current addDeferredUIMessage: [ Transcript show: theMessage; cr ].


Levente

>
>
> tim
> --
> tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim
> The hardness of the butter is proportional to the softness of the bread.