Hi,

Currently Squeak Smalltalk does not use real operating system threads (or a
real threads library like pthreads) so if you need real threads on a
project you may need to choose another language. Oh no not C++!!!!
Actually, you can continue to use Smalltalk and gain the benefits of real
threads.

There are Smalltalk's out there that use real operating system threads. For
one example check out Smalltalk MT (for Multi-Threaded) for Windows
95/98/NT platforms:
	www.objectconnect.com

An exerpt from the Object Connect web site follows.

Smalltalk MT is fully multithreaded and all primitives are reentrant.
Threads are very lightweight and share a common address space, which is
consistent with the way threads are used on Win32. The system is scalable
and can benefit from multiprocessor architectures. 

Robust multithreaded implementation: Smalltalk MT is multithreaded from the
ground up, with garbage collection running in a separate thread. A process
can have any number of threads. This enables the development of scalable
applications on Windows NT, and simplifies considerably the design and
implementation of applications that use blocking I/O. There are no
restrictions on sharing data between threads (other than
application-specific synchronization issues). In addition, all Win32
synchronization mechanisms can be used, which enables a non-Smalltalk
thread or process to synchronize with a Smalltalk thread. 

Thread local variables: Smalltalk MT introduces thread local variables,
which are instantiated per thread, and visible from any code executed by
the thread. 

Exerpt ends.

With Smalltalk MT you get full threads but your application must handle
it's own synchronization like any application using threads in any language
(C, C++, Objective-C, or Java). 

The disadvantages of using Smalltalk MT are that it currently only works
with Windows 95/98/NT platforms. 

The advantage of Smalltlak MT is that it's fully multithreaded and is
tightly bound with the Windows 95/98/NT plaform. This is good if you have
to deliver a Win32 based application and way better than using C++ for the
job. It's also very fast and can produce very small runtime application
..exe's. It can also produce headless server style runtime systems.

Another disadvantage is that your working with a commercial smalltalk
without the source code so you become dependent upon the vendor,
ObjectConnect, to keep current with Windows developments (they do seem to
be excellent at doing this). They also seem very responsive to technicial
critisims (I needed symbols in the runtime image, their runtime vm had been
optimized symbols into integers like Objective-C does for speed, and so I
sent them an email and they put out a new vm with an option to preserve
full symbol functionality in a runtime vm within a couple of days!). They
are also willing to enter into source code escrow agreements with clients
who need this type of safetynet. Maybe they might be willing to open their
source code up if a lot of people ask?

Also see the Smalltalk Industry Council web site for other smalltalk
vendors.
	http://www.stic.org/

Choosing which Smalltalk to use for a project can be difficult at he best
of times.

All the best,

Peter