Any Questions about or Suggestions for the next release?

[Darin McBride]

On Wed, 1 Sep 1999 06:34:17 -0700, Steve Lamb wrote:

>Wednesday, September 01, 1999, 6:31:48 AM, Darin wrote:
>> That's nice and all, but the bottom line is that it's correct - for the
>> message queue thread only.  Which is how it would get across to Bob&Ike
>
>    The bottom line is that he wasn't clear.

To you, or to Bob&Ike?  Which matters more?

>> [Technically, it's also accurate if you anticipate users having SMP.
>> But I doubt too many users who have PMMail/PMINews have OS/2 Warp
>> Server SMP or OS/2 Warp Server for e-business on an SMP box... :-)]
>
>    Technically, you're wrong.  The longest operation in the machine, and
>hence, PMMail, is disk operations.  Having 256 threads spread across 256 CPUs
>still won't speed up the disk.

Um, no.  Well, maybe if you have IDE.  The disk will make one read
operation out of it, send all of the data to be processed in parallel,
and still speed it up.  But you're throwing red herrings all over the
place, and I can't keep up.  First, we started with "use another
thread" for a specific item (0.1s response time in PMMail).  You made
that into a generalization.  I answered the generalization with a
generalization (qualifying that it didn't apply to our specific
example).  You answered that with a specific example.  Are we
generalizing, or are we talking about this specific example?

In this case, throwing an extra thread at it *WILL* improve performance
(negligably) and improve responsiveness (significantly).  Throwing a
hundred threads at it will most likely destroy performance, and also
responsiveness (see: PMINews).  In general, parallelisable tasks (of
which we only really have two - the UI and the listbox update) get
tremendous speed boosts from multithreading, especially on SMP
machines.  This generalization only applies, in this case, for our two
tasks.