Squeak libraries are generally written non-thread safe. Where you intend 
to have interactions of multiple threads, you coordinate them, such as 
by using the specific thread safe data structures. Some of those are 
SharedQueues (or something like that) and the Transcript.

Daniel

Ross Boylan wrote:
> My recent adventures led me to this code:
> Set>>grow
> 	"Grow the elements array and reinsert the old elements"
> 	| oldElements |
> 	oldElements _ array.
> 	array _ Array new: array size + self growSize.
> 	tally _ 0.
> 	oldElements do:
> 		[:each | each == nil ifFalse: [self noCheckAdd: each]]
> 
> If another squeak thread (NOT native thread) interrupts this
> operation, isn't there a possibility for bad things to happen?
> This operation might be triggered any time an element is added to a
> set.
> 
> A variation that constructed the new array first might be a bit safer,
> but it could still have problems if something was added or removed
> from the set in midstream.
> 
> Subclasses of Set seem to have similar issues.
> 
> I thought smalltalk was supposed to be thread-safe with respect to its
> own threads.  Am I mistaken in that belief, or in my analysis that the
> operation is not thread safe?
> 
> I'm aware that the solution would exact several kinds of penalties
> (clarity, speed, memory).
> 
> Ross Boylan
>