Follow-up Comment #2, bug #28757 (project gnustep):
Yes, it really does happen.
I looked at NSThread.m in the svn repository, and I agree with you that it
seems to reduce to a simple Sleep() call, which should work correctly.
However, I did notice one interesting thing. The MINGW32 code looks like
this:
while (delay > 0)
{
Sleep (delay*1000);
delay = when - GSTimeNow();
}
If for some odd reason Sleep() returns early and doesn't sleep the "whole"
time, then the delay would be recalculated and the loop would continue again.
What you proposed was to print out what value is being passed to Sleep() for
each iteration, correct? This would require me to recompile GNUstep on mingw
(I believe). I'm not sure I really want to do this.
Finally, it seems that anytime I try to call [NSThread sleepUntilDate:d];
where d is greater than 1 second in the future, it pegs one processor for 100%
usage. Anything less than 1 second in the future and that problem disappears.
In either case, the method doesn't return until the proper amount of time has
passed, but CPU usage seems to be amiss in one of the cases.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?28757>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnustep
