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.