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. 

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

Right;  use Wait-for-something in it's own thread.


 DM>     So unless my understanding of a thread is 
 DM> mistaken. (I personally use a 
 DM> loop the same as I would with DOS, but then "I" don't

You're still going to use a loop.  It will be something like this:

void ReadThreadThatRunsForever()
{
        for(;;){
                DosRead(...);           // will block for several seconds
                                        // if no data is available.

                ... place code here to use the bytes,  or to buffer it
                ... later for another thread's use.
        }
}


 DM>     That is, a dosread(port,4000,numberread) takes the 
 DM> same amount of time, 
 DM> regardless of whether it reads a single byte or all 
 DM> 4000. This is the main

THen you didn't set the port to wait-for-something mode.

 DM> programming for OS/2. And perhaps 
 DM> my understanding that a thread must be allowed to 
 DM> sleep to release control to 
 DM> the rest of the program is flawed.

You're right about your being wrong .  DosSleep() is proably one
of the WORST ways to "release control";  it is much better to
block in a device driver (for example,  in a DosRead() call) that will only
wake you up when you have some real work to do.

For example,  I have seen this in an os/2 program:


        while(!kbhit())
            DosSleep(1);
        key = getch();

This is _absolutely insane_.  It should simply be:

        key = getch();


I have seen this too:

        while(!kbhit()){
            UpdateClockOnScreen();
            CheckForBytesFromModem();   // or some other such thing
            DosSleep(1);
        }
        key = getch();

This is just a little less insane.  The UpdateClockOnScreen() should be
trown away (this is OS/2 after all,  and the user can start a clock on his
desktop),  and the CheckForIncommingData() should be in its own thread
(that is blocked in a device driver,  not simply calling DosSleep!).


--- Maximus/2 3.00