CS> This thread, which repeatedly retreives data from the INI files and 
 CS> scans it for specific substrings, brings my P90 to its 
 CS> knees.   Everything else is VERY slow whilst the 
 CS> scanning is taking place.  However, adding a 
 CS> DosSleep(1) to tell the thread to give up its 
 CS> timeslice now and again seems to cure the problem.

 CS> Why is this happening?  OS/2 isn't supposed to let one 
 CS> process hog processor time like that, is it?  Is it 
 CS> something to do with the message queues?

It is not a message queue problem, else the DosSleep(1) would make it even worse.

The Prf...() api is not very efficient,  and (since OS/2 2.1) is working
off an in-memory copy of the INI files (so the disk device driver never
gets the opportunity to block the thread to wait for i/o to complete).

In this case,  OS/2 has decided your thread is cpu-bound,  and is doing
real work -- so it preempts the other threads to give you a boost.  If you
(the programmer) know that this is indeed not real important work,and you
are not waiting on an hardware event,  the DosSleep(1) is probably a good
solution;  as is lowering your priority to the second lowest level in the
idle class (the lowest level should always be reserved for Pulse).

ps: The dynamic priority adjustment I described is true when your thread is
in the Regular class and you have "priority=dynamic" in
config.sys (the default).


--- Maximus/2 3.00