4 ms·
It's this bit of code: while(GetMessage(&msg, NULL, 0, 0) > 0) { TranslateMessage(&msg); DispatchMessage(&msg); } The mouse isr
by snarfy 7y ago
It's this bit of code:
while(GetMessage(&msg, NULL, 0, 0) > 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
The mouse isr would cause a loop like this to execute at some point, processing all the messages on the queue. Win95 had preemption, but it ran at 100hz. Moving the mouse caused additional queue processing on top of the time sliced preemption.
- cantstop 7y agoAt that time, it was more like the 75mhz range.
- achandlerwhite 7y agoNote he said 100hz not mhz. Essentially 100 times per second the message queue would process but if you moved the mouse it would process faster.
- the-dude 7y agoAnd the BSDs and Linux also have the HZ parameter for scheduling and for a long time the default has been as low as 100 Hz. Not sure what the current status quo is.
- brandmeyer 7y agoTickless
- trasz 7y agoFor FreeBSD it's been 1000 for... ages, except for virtual machines, where it seems to be 100 by default.
- asveikau 7y agoSome guides for better battery life on FreeBSD recommend setting it to 100 Hz.
- kllrnohj 7y agoLinux's default varies per architecture & platform. For a long, long time on ARM it still defaulted to 100hz. I think it's more like 250hz or 500hz now? You'll also see x86 desktop-focused build set it to 1000hz. But scheduling happens far more often than this tick rate, too, so it's only preemption for busy threads and controls the timing windows for things like DVFS.
- tempguy9999 7y agoI thought the windows clock defaulted to ~60Hz. I understand it could be pushed up by software to 1Khz for audio players to work correctly. I may be very wrong on the latter point though.