On Friday 07 December 2001 12:52 pm, Joe Graham wrote:

> okay, well i guess what i was looking for was an OO implementation around
> pthreads (or wotever) the native threading scheme is.  Ruby and Java (of
> course) have nice implementations of native multithreading APIs. 

Ruby has its own threads, much like Squeak's (similar to Java's "green 
threads"). Ruby takes more care to avoid blocking on file I/O, however. 
Squeak has had async file I/O on some platforms, but I don't think it's 
universal.

There are people who would like to see native threads being used (in Ruby as 
well as in Squeak) but this would be a pain because of the different thread 
APIs (and Ruby, like Squeak, also runs on platforms that don't necessarily 
have their own threading model).

>  Utimately
> you only get signaling since threads are just a subprogram/process.  But it
> is nice to be able to have an API that deals with issues like "join",
> "rendevous", "wait", mutex, sem etc..

Which can be done regardless of native/non-native threading. Squeak has a 
Semaphore class that can be used for a variety of patterns. Ruby has its 
global Thread.critical flag.

> However if the pattern is to use "message queueing" in Smalltalk (or maybe
> just squeak?) then perhaps it is the better approach.  I guess you can
> fork, create a new process or whatever all with the same mechanism so it
> sounds very appealing.  What I wanted to know is if this is the general
> approach or is this just a "workaround" for green threads?

I don't know what you mean about "workaround". As Lex said, the basis of 
concurrency management in Squeak is the Semaphore (and of course the 
scheduler itself).

-- 
Ned Konz
currently: Stanwood, WA
email:     ned at bike-nomad.com
homepage:  http://bike-nomad.com