On 2/14/02 1:46 PM, "Daniel Joyce" <daniel.a.joyce at worldnet.att.net> wrote:
> Personally, I find threading to be a issue designed last. About the only
> threading most programs need is when A) Something takes a very long time to
> render onscreen  and B) does lots of disk access.
> 
> If you got a good compartmentalized design, then one can usually go back
> and add threads to the necessary parts of A & B above.
> 

Hi Dan,

You are right about the 2nd part.

I have a lot of experience with threaded systems designs, having developed
several process control and machine control systems in Smalltalk many years
ago.  Threads are often, as Lex put it, "tricky" to keep straight in your
mind.  Back when I used to do troubleshooting for Digitalk Professional
Services, I often found myself fixing problems with threaded designs in
customer's applications.  The most common use I saw was connections to
external systems like Relational Data Base systems.

But I digress.  I think the premise here is wrong.  It's actually the most
natural model to design things as if they were easily threaded.  I'd bet
that folks who have never programmed computers before tend to approach a
complex programming problem by naturally thinking in threads.  For me at
least, I tend to view each object I encounter as a some kind of abstract
"living" thing - quote capable of existing in a thread.  The truth is it
usually the damn process model that breaks everything because the
interactions are not thought out.  Global variables, Class variables,
Digitalk's PoolDictionary.  Those are killers.

 - Steve