Squeak and threads

Joe Graham joe at aiobjects.com
Sat Dec 8 01:51:31 UTC 2001


Thanks for the useful info on Ruby.  I might have been thinking of Python or
I don't know what.  However I remember cruising through some C code in
someone's interpreter and seeing something like.
#ifdef __PTHREADS__
// use pthreads
#ifdef __WIN32_THREADS__
// use windows native threads
But in any case my question is really what is the usage pattern?  I
understand that concurrency patterns just deal with communication between
two processes.  In the case of a thread, a parent and child process.  No
biggie.  But I would like to know more about how you would use a message
queue to accomplish this.  Or at least what a general usage pattern would be
to for example say implement a socket server capable of handling concurrent
requests. What would be an general design pattern (or combination of
patterns) in this case?

As for the "workaround" comment I meant that you could take some approach to
implement a system that would be suitable in a situation where threads
provided by the VM are not otherwise acceptable.  I tend to forget that on a
technical mailing list one needs to be specific.  My apologies there.

Thanks again.
-joe


-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf Of Ned
Konz
Sent: Friday, December 07, 2001 2:52 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Squeak and threads


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





More information about the Squeak-dev mailing list