I'll throw onto this discussion. I believe tim tested the TraceMonitor, 
but went with Toothpick, which I have never used.

TraceMonitor (package in Cryptography) is mutex protected and writes to 
multiple streams, including the Transcript. Therefore, multiple event 
loops or other background processes can concurrently write to Transcript 
and it will be properly interleaved.

K, r

On 9/13/20 3:06 PM, David T. Lewis wrote:
> On Sun, Sep 13, 2020 at 11:29:38AM -0700, tim Rowledge wrote:
>> The recent discussions about change logs etc, along with thinking about how the Toothpick package might do the job better (just realised that one could add an MQTT logger to it so that clusters of images could simply publish the logs and 'normal' tools could be used for sysadmin purposes) have reminded of a problem that has bitten me a couple of times over the last few weeks.
>>
>> Basically, if we have a non-UI process (like Seaside handling) that tries to send something to the Transcript, then just occasionally and always, of course, during a demo, it will cause a problem. Obviously, I can't find a log file of it happening to illustrate; that would be far to helpful. IIRC it's something relating to the re-layout phase of the text morph.
>>
>> Now I'd swear (and did!) that we 'fixed' this several years ago but I can't find any email about it so maybe I'm just hallucinating again.
>>
>> Has anybody else seen this, or can remember about it or... ?
>>
> This does not answer your question, but just in case you have overlooked
> it, "OSProcess trace: something asString" is useful for dirt-simple logging
> to the console from any process. I have never trusted the Transcript for
> things like that.
>
> Dave
>
>