Eli Zaretskii wrote:
On Thu, 29 Mar 2001, Maurice Lombardi wrote:
What I'm wondering is, if DJGPP's libc contains a delay() function which does handle short delays well (and even seems to use microseconds internally AFAICS), why doesn't its usleep() function do the same thing?
If both functions used the same service, you couldn't have chosen one or the other, depending on your needs. Having both is better than only one.
Why is it a problem that they use different methods? The docs clearly says what service is used, so the information is available, isn't it?
Well, usleep() is a common function of many systems (though not POSIX, I admit), so I think it might just be a good idea if it produced good results for short delays (which is one of its main uses).
In the case discussed here, the PDCurses library implements its napms() function by a call to usleep() (because it is multi-platform), and that's what the Delay procedure in GPC's CRT unit calls, so calling Delay with a small argument doesn't do anything, like Opie Pecheux reported.
To fix it, we'll have to make a conditional change for DJGPP to call delay() rather than usleep() in either PDCurses or CRT as well as in any other code that uses usleep(). Having DJGPP's usleep() do the right thing for short delays, in contrast, would only be one change in a single place...
Frank