Newsgroups: comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!news.sprintlink.net!uunet!world!edwards
From: edwards@world.std.com (Jonathan Edwards)
Subject: Re: c++, smalltalk, and real-time
Message-ID: <D74tw9.M8A@world.std.com>
Organization: IntraNet, Inc.
References: <abb650be010210046007@[192.55.204.253]>
Date: Sun, 16 Apr 1995 14:36:09 GMT
Lines: 30

In article <abb650be010210046007@[192.55.204.253]>,
David Simmons  <quasar@QKS.COM> wrote:
>Your comment that "Smalltalk in particular does not support multithreading
>and multiprocessing..." is not correct.

You stated in an email to me that you had no planned capability to
multiprocess Smalltalk. As in running Smalltalk code in parallel on multiple
processors in an SMP configuration. Therefore you do not do
multithreading and multiprocessing in the common usage of the terms.

Let me agree however that you seem to have the most advanced commercially
available implementation when it comes to these issues. True pre-emptive
scheduling within Smalltalk is very important, and you seem to be the only
one doing it. I expect you have the best interupt latency.
And without doing any actual tests I would still bet that you
have the best integrated and most lightweight access to external threads.
All the stuff you mention about integrated access to external data structures
and networking is great. All this would be really compelling if you only
ran on the platforms my customers want to buy...

But interfaceing to external threads is not the same thing as multi-threading
Smalltalk itself. If it only runs on a single CPU, it isn't really
multithreaded, and it certainly isn't multiprocessing.

Stop reading USENET and get back to work on DR/3 ;)
-- 
Jonathan Edwards				edwards@intranet.com
IntraNet, Inc					617-527-7020
One Gateway Center				FAX: 617-527-6779
Newton, MA 02158
