JRC> more efficient to buffer
 JRC> the comm port with a thread in the program, or 
 JRC> not to worry with it. 
 JRC> I've been turning that one around in my head for 
 JRC> a couple of days and
 JRC> I can't see where the overhead would be worth it ...


Doing i/o to different devices, each in their own thread,  allows OS/2 to
overlap i/o;  definitely worth the effort for any type of program.


 PC> If its a PM program I would use a thread to avoid blocking the message
 PC> queue (main) thread for too long.

 PC> Also by using a secondary thread you can adjust the priority.  In my app
 PC> the thread that reads the com port runs at PRTYC_TIMECRITICAL and all
 PC> the other threads run at PRTYC_REGULAR.

This may actually be counter productive;  by servicing the device driver
too often,  you will call DosRead() more often (then if your thread was
running at a lower priority).  The DosRead() calls will transfer fewer
bytes with each call (perhaps as low as 1 to 10 bytes).  Since the overhead
of calling DosRead() is _huge_,  you want to call it as few times as
possible,  and get as many bytes back with each call (this is why
"Wait for something" read timeout processing is so cool).

By lowering the priority,  and DosReading, say, 100+ bytes at a time (and
10 times fewer DosRead calls),  your throughput will actually increase (and
your cpu load will lower drastically).

I have written a lot of OS/2 comm software.  None of them use time
critical.  What I usually do is run all threads at "regular", and
allow an option to run at "foreground server" for taxed systems; 
for the later,  however,  I raise the priority of all of the threads,  not
just the comm thread,  so that the balance I described above is maintained.


--- Maximus/2 3.00