> 
> "Pennell's" <pennell at tiac.net> wrote:
> > >I have to agree.  Pthreads are being utilized by more and more
> > >efficiency conscious applications (Apache, MySQL, etc) every day,
> > >there's no reason why Squeak should shy away from such a requirement,
> > >IMNSHO.
> > 
> >
.... more discussion ...
> > 
> I agree that Squeak *should* shy away from making a threads requirement for all platforms.
> First, it would ruin our three-week ports, as porters try to make their native threads act
> as Squeak's semantics require.  Second, it would add another way for behavior to be
> different on different platforms.
> 
> Lex
> 

I would suggest the following guideline when considering the use of
operating system threads in Unix (Linux) systems:

  Whenever possible, use simple OS processes rather than using threads
  within an OS process. Rely on the basic abstractions of OS processes
  (created by fork and exec) communicating through OS streams (stdin,
  stdout, and stderr). Never implement cooperating OS tasks at the thread
  level unless it is certain that the simple OS process model is
  insufficient.

Rationale: Consider this issue to be loosely analogous to the question
of whether to implement a piece of Squeak behavior in the VM, or in
the Smalltalk classes. Whenever possible, implement in Smalltalk;
only if this is known to be insufficient do we resort to using C code
in the VM. Similarly, we should not add either complexity or
unnecessary features to the VM using threads if it is possible
to get the job done in an external OS process. In particular,
with respect to performance, just as we should never assume
a priori that "Smalltalk would be too slow" for implementing
a function, we should not assume that the OS process model provides
insufficient performance until it has been tried and demonstrated to
be inadequate.

Corollary: Squeak will need classes to represent the Unix OS
abstractions, such that an OS process can be set up and communication
established through OS streams. The concept of a Squeak image
communicating with an external process (such as a web server),
already exists, so we probably need only the minimal machinery
required to support fork/exec and stdin/stdout/stderr redirection.
Similar issues would be exist for a Squeak image running any OS which
supports multitasking, so we would want the new classes to be
factored in ways that would be friendly to other (eg Windows)
systems.

Dave Lewis