> WV> Also, when you do not have a 16550 with a FIFO, you probably
 > WV> be better of letting the read task just put the stuff into a
 > WV> buffer which is read by another thread. 

 > GB> Oops! DOS-ism detected! You *shouldn't* take into account
 > GB> which hardware you're using. OS/2 does the buffering, and
 > GB> has a big enough buffer to prevent the UART from overflowing

 WV>It is my experiantation that it does matter, before I had an 16550 I
 WV>would get transmission errors when switching tasks.

The 16550 matters, but whether you read inline or in a separate thread
doesn't.  The com driver is taking care of actually reading the port,
not your app.  It'll buffer 'em until you need 'em.  If you're in a
situation where you can't keep up with the com driver, a separate thread
is again not likely to be of much help, as you'll eventually not be able
to keep up with its secondary buffering -- there'd be a basic design
flaw in your program.

I suppose there are cases where a secondary thread would be beneficial,
but just to do again what the com driver is already doing (read and put
into a buffer to be pulled out by another thread) isn't really a reason
as such.  Someone else (Jon Guthrie) indicated that he got timing
control he needed using a secondary buffer.  I'm not sure how that is,
but you might talk to him about it.

For what I have experience with -- generic BBS stuff -- secondary com
threads are generally a waste of CPU.  However, I can envision situations
where it might be handy.  For instance, a protocol that took interweaved
packetized information and passed it to different threads for different
purposes.

--- XHEd-OS/2 1.22