-=> Quoting Peter Fitzsimmons to Phil Crown <=-



 PF> I have written a lot of OS/2 comm software.  None of them use time

 PF> critical.  What I usually do is run all threads at "regular", and

 PF> allow an option to run at "foreground server" for taxed
systems;  for

 PF> the later,  however,  I raise the priority of all of the threads,  not

 PF> just the comm thread,  so that the balance I described above is

 PF> maintained. 



 Hmmm.  That's an interesting spin on the problem.  I hadn't though of that

 to be honest ... :)  I've been playing with your PMTERMSR.LZH file.  Clean

 code although I don't understand a lot of it (particularily the PM stuff).

 So, in your opinion, I should have a thread that deals with incoming comm

 bytes, a thread for outgoing comm bytes, a thread for disk reads, a thread

 for disk writes and a "traffic-cop" thread?  For serial I/O that seems a

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

 group of bytes) at a time.  Output I could see a separate thread, but for

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

 waiting for me and let the OS be the thread.



 I guess the other question would be, if I do go ahead and do a thread for

 input and one for output how would I go about making this dumb thing a C++

 class or something ...  That's my other sticky question.  :)



 ={) James (}=



--- Blue Wave/DOS v2.30