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
|