> MK> For what I have experience with -- generic BBS stuff -- secondary com
 > MK> threads are generally a waste of CPU.  However, I can envision

 PF>Just because a thread exists does not mean it is using more CPU.

If the thread exists for the sole purpose of duplicating what the com
driver is doing, it's a waste of CPU.

 PF>A secondary thread,  with the proper read mode
 PF>(wait-for-something),allows you to miminimize the number of
 PF>DosRead's you have to do,  thus saving _loads_ of CPU.

If you do nothing but read-and-buffer in your "secondary thread" you'll
wind up doing _more_ DosReads for the same number of bytes, just as
you'll make more trips to a dripping faucet to get a bucket of water if
you insist on carrying each few drops back to the house for someone to
drink instead of waiting for a glass to fill.  Try it, I did.

OTOH, if your read thread is doing work between reads, it can make sense
(as in a read thread that packetizes the information and hands off to
appropriate threads).  Com ports are too slow to benefit from
double-buffering strictly for its own sake -- allowing the com driver to
get a bit ahead so it can return more bytes per read makes sense.

 PF>It also :

 PF>    - allows a much larger buffer than the puny one in com.sys,

Linear inline buffering takes care of that (read a lot, buffer excess
for later use).  I use an 8k linear buffer, for example, but it never
gets full.  Add in a better com driver (SIO with 4k internal buffer) and
there you go -- no problems at all.

 PF>    - better lends itself to having a data-driven design in your program.

What's the difference between asking your secondary thread for the data
and asking the com driver for the data as far as "having a data-driven
design in your program?"  You have one function which returns data.
Whether that data came from the com driver on that call or was buffered
earlier, your program neither knows nor cares.

 PF>    - "does nothing" better.

Blocked is blocked, Peter.  If you feel like waiting up to 15 seconds
for something to come in, tell the com driver you're willing to wait
for, say, up to 15 seconds for something to come in.  Whichever thread
is looking for the data will block for 15 seconds (unless data comes
in).  In your scenario, two threads block.  In mine, one.  There's your
difference.

I realize that you're used to being considered an expert on the subject
due to maxcomm.dll, and I wrote my first com code under OS/2 just as
you did.  But I tried it inline and, with typical generic BBS stuff,
inline works better.  Sorry, Peter, you can't always be right.

--- XHEd-OS/2 1.22