Transcript is not thread-safe???

jchludzinski at worldkey.net jchludzinski at worldkey.net
Sat Oct 28 06:51:00 UTC 2000


Ned,


>Hmm, why a class variable? It should be an instance variable, in 
>case you want to make, for instance, Transcript2 (another 
>TranscriptStream).

I wondered about that too but at the time I had a prototype to demo 
and I didn't have the time to debate if this was optimal or not.

>All this does is serialize #endEntry, which only works for calls 
>to #endEntry, or atomic calls to #show: (which also calls 
>#endEntry) FROM THREADS WITH THE SAME PRIORITY.

All any critical sections (of code) do is guarantee mutual excution 
- i.e., serial execution.


>Morphic was not designed, as far as I can tell, to deal with 
>multiple threads. (For instance, what happens to the Transcript if 
>you're manually editing or scrolling while logging from other 
>higher-priority threads? Resizing? Selecting?)

I hope there's NOTHING inherent in Morphic which makes it ill 
suited for thread-safety???  Isn't Java's Swing (set) thread -
safe???  Since Squeak support Processes (heck, there are many 
concurrently executing at any one time in Squeak - I monitor the 
count), shouldn't the TranscriptStream be made thread-safe?  
Shouldn't Morphic be made thread-safe?
 

---John








More information about the Squeak-dev mailing list