-=> Quoting Peter Fitzsimmons to James R. Cook <=-



 PF> If you are reading and writing to the same disk,  using two threads

 PF> for this will not help.  Plus -- OS/2's cache (esp HPFS) supplies the

 PF> threads for for anyway. 



 Yeah, that makes sense.  Does that apply to a couple of files on the same

 disk?



 PF> I don't know if you need separate modem read and write threads;  it

 PF> depends on what your program does.  If it mostly receives bytes (a

 PF> terminal program) that you definitely want a separate modem read

 PF> thread. If it spends all day sending (some sort of HOST program),  you

 PF> want a write thread.  If it does a lot of both,  do both (the modem is

 PF> one of the only devices on your PC that is full duplex -- you can be

 PF> both reading and writing at the same time at the hardware level). 



 It's closer to a host proggie.  I would assume that input would be pretty

 minimal and that output might need a separate thread.  Particularily if

 I'm tweaking the output prior to it getting written to the port.

 

 JRC> serial I/O that seems a

 JRC>  bit redundant.  For my needs, I'll be reading a single byte (or maybe a

 JRC>  group of bytes) at a time.  Output I could see a 

 JRC> separate thread, but for

 JRC>  input, I could make the input non-blocking and just see if anything is

 JRC>  waiting for me and let the OS be the thread.



 PF> If this is some sort of handshake protocol,  where you get a few bytes

 PF> (to 1k or so) ( and will not get anymore until you handshake),  your

 PF> reasoning is perfect;  the interal COM.SYS buffers will never

 PF> overflow. 



 Right.  But it's a bit more complicated.  My message to Mr. Crown has more

 info.



 PF> If you are also writing fairly small packets (a few K or less) as a

 PF> response to each incoming request,  you may as well skip the write

 PF> thread too -- COM.SYS's write buffer will do the work for you. 

 PF> Most of my ramblings over the years, re modems and efficiency,  assume

 PF> a steady (and/or unsolicited) stream of bytes (for example zmodem). 

 PF> If you are working on some handshaking code (something like xmodem or

 PF> FTP),your code need not worry too much about efficiency. 



 Hmph.  That's what I was afraid of.  I do think it'd be worth the effort

 to have an output stream.  Since the program will deal with individual

 keystrokes and spit out screens worth of info, that'd be optimal I think.



 Thanks for the words of advice!  It seems that programming nowadays takes

 more than one brain working on it ...



 ={) James (}=



--- Blue Wave/DOS v2.30