Re: Thread problem...

From: Phlip (phlip_cpp_at_yahoo.com)
Date: 12/04/03 

Date: 4 Dec 2003 11:45:09 -0800

Stewart Gordon stands accused of writing:

> While it was 29/11/03 1:09 pm throughout the UK, Phlip sprinkled little
> black dots on a white screen, and they fell thus:
> <snip>
> > Thirdly, our industry horribly over-uses threads. Your documentation will
> > not tell you this, but the only reason to ever use them are certain hardware
> > and device driver shenanigans.
> <snip>
>
> So, what would you use instead to carry out calculations without
> blocking user input e.g. to interrupt the calculation?

I personally believe there is no possible algorithm that would not
benefit from expression as an object model with discrete events to
change it towards its solution, but the science isn't advanced enough
yet to refute or support me.

In practical programming terms, if you are driving with one hand and
eating a sandwich with the other, use threads.

But the documentation for threads typically provides very poor role
models. It might show examples of waiting at two COM ports at the same
time. While this assists those who already think they need threads, it
might disadvantage programmers who need to wait at two COM ports at
the same time and think the example code shows the "standard" way to
do it. All multitasking OSs support a 'select' or Multiplex system to
await any set of multiple events at the same time. Using them will
force your code that responds to those ports to show a better design.

I know a programmer who heard of threads before they heard of the
Win32 message architecture's notification system. That is pleasantly
synchronous and robust. 

-- 
  Phlip