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
|