-=> Quoting Mike Bilow to David Muir <=-

 MB> You don't need DosTimerAsync(), which consumes a system timer
 MB> resource.  You need, instead, to read and store the system time of day
 MB> and sleep for a while, waking up every so often to check if the
 MB> required interval has passed, then sleeping again for about half the
 MB> interval remaining: 

    I was "hoping" to block it in a semaphore, but by the looks of things, 
that action is either "not worth it" or "consumes resources
it need not". In 
either case, Peters suggestion seems to do the trick with slightly less 
overhead than my previous method (athough I'd still prefer a blocked thread if 
it's possible and not too hungry).

 MB> semaphores named in the "\SEM32" hierarchy.  You can find the
 MB> documentation for the 32-bit calls in the Control Program Reference
 MB> (GUIREF20.INF) rather than PRCP.INF. 

    I did manage to figure out how to assign a 32bit semaphore (although I 
haven't figured out how to use 'em ). I don't suppose the above file is 
publically available (GUIREF20.INF)? I'm using VP and don't have the benefit 
of the docs supplied with commercial compilers.

 MB> You don't need DosTimerAsync() to sit around and wait for 60 seconds
 MB> of absolute time.  You are wise to do something more sophisticated
 MB> than DosSleep(), which measures process CPU time, if absolute time is
 MB> important. 

    I'm not actually "waiting" for 60 seconds per ce. I'm
"counting" seconds 
of which the number can vary depending on the task in hand.

 DM>     Of course if I'm just looking too hard in the wrong
 DM> direction, I'd settle  for being pointed in the right
 DM> direction.

 MB> Aha!

    okay.. now that that is settled, is it possible to run such a thread which 
is blocked by a semaphore rather than using dossleep? Call it curiousity.

Dave...

~~~ TGWave v1.12+
--- GEcho 1.11+