-=> Quoting Peter Fitzsimmons to David Muir <=-

 PF> It is better to use "Wait for something" read timeout processing; 
 PF> this way,your application is blocked in the DD -- who is the one who
 PF> knows the instant something is avaiable. 

    Now understand that I don't profess to be near the programmer you are, but 
the "original" request was calling a "thread"....

 PF> There is no need to call an ioctl to see if characters are waiting.

 PF> There is no need to call DosSleep

    So unless my understanding of a thread is mistaken. (I personally use a 
loop the same as I would with DOS, but then "I" don't have the
experience with 
OS/2 that I might have otherwise) a thread is basically a task of it's own. 
This being the case (assuming he is going to use the port read as a thread), 
he most certainly MUST use dossleep (else never exit the thread).

 PF> 1) Put port into "wait for something" mode.
 PF> 2) Set a long timeout (>5000ms).
 PF> 3) In an infinite loop,  call DosRead() with a large (>1000)
 PF> buffer.  If it returns ByteRread == 0,  it means it timed
 PF> out (a good time to test the carrier).
 PF> 4) If it returned BytesRead > 0,  your program got the bytes
 PF> without hesitation (ie: DosRead() does not wait for your
 PF> whole buffer to be filled if there is a pause in the
 PF> incoming data) .

    And while I don't dispute this (and perhaps it works fine for you). In my 
original implementation of my modified term program I did this (or something 
similar anyway). I found that VP does indeed take a considerable amount of 
time to read a single character from the port if it has been told to read a 
large number of bytes.
    That is, a dosread(port,4000,numberread) takes the same amount of time, 
regardless of whether it reads a single byte or all 4000. This is the main 
reason "I" check for incoming characters and read only the number of 
characters waiting (this action alone sped up my incoming datastream by 
tenfold).
    Now in my own defence, I do not program in "C" and therefore
don't even 
have a reasonable amount of documentation on programming for OS/2. And perhaps 
my understanding that a thread must be allowed to sleep to release control to 
the rest of the program is flawed. And "maybe" what you're saying
works just 
fine. But in my experience reading "the size of the buffer" is
far too time 
consuming and makes the input VERY choppy.
    My implementation on the other hand. Using a loop rather than a thread, 
checking the number of incoming bytes and reading the number incoming 
"precisely" moves very quickly and very smoothly. I suspect that moving my 
reads to a thread might speed this up slightly, but due to another property of 
my program, I find that to be impractical in "this" instance
(although were it 
not for that single consideration which could be construed as an oddity) there 
would be no reason not to move it to a thread.

    Now on the other hand, "I" don't exactly intend to be
programming terminal 
programs and was offering my insight only based on what "I" have
found to be 
the case with VP.

    As a last comment, it is of course possible that I have misinterpretted 
(or simply not understood) what you typed above, which resulted in my having 
misconceptions about it's effectiveness. If you would care to translate that 
into code (Pascal preferred but C woud be acceptable), I would be happy to 
replace the relavent portion of "my" code with it and report the
results (and 
who knows, I might even learn something ). Again I don't profess to be a 
programmer of any skill, and would welcome the opportunity to see where my 
logic is flawed and "if" what you suggest is better, I would
certainly like to 
understand "why" and correct my logic accordingly.

    Sorry for the long message. I sometimes find it difficult to express 
myself adequately in a limited space.

Dave...
~~~ TGWave v1.00 Beta-05g [NR]
--- GEcho 1.11+