Hi Marcel,

No, it's not. Its sole thread safe method is #endEntry (and #flush of 
course, which simply sends #endEntry). Without #endEntry being thread 
safe, race conditions would be a lot more common.

(Part of) Its API could be made thread safe, and it could also be enhanced 
in many ways. The main problem here is that it is a subclass of 
WriteStream, so it inherits way too many (unnecessary) methods.

Making individual methods thread safe wouldn't be enough IMO. It would be 
better to provide thread safe methods which generate complete messages 
before writing them to the stream in a thread safe way. E.g.: #stream:

Transcript stream: [ :stream |
 	stream
 		nextPutAll: 'Hello';
 		space;
 		nextPutAll: 'World!' ]

or #nextPutAll:format:

Transcript nextPutAll: 'Hello {1}!' format: { 'World' }.

These would be better than making individual writer methods thread safe, 
because the latter couldn't prevent mixing messages from different 
processes. These variants would also perform better because of fewer 
synchronization points.


I usually use the following workaround to achieve thread safety:

| message |
message := 'Hello {1}!' format: { 'World' }.
Project current addDeferredUIMessage: [ Transcript show: message ]

This works because Transcript instances process the stream from the UI 
process.

Levente

On Tue, 5 Apr 2016, marcel.taeumel wrote:

> Hi, there!
>
> TranscriptStream >> #endEntry uses a semaphore and critical section.
>
> TranscriptStream >> #nextPutAll: does not. :-/
>
> But TranscriptStream >> #nextPut: is a primitive.
>
> So, is Transcript thread-safe?
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Is-TranscriptStream-thread-safe-tp4888382.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>