On Sat, Mar 10, 2012 at 04:35:26PM +0100, "Jérôme M. Berger" wrote: > Adam D. Ruppe wrote: > > On Saturday, 10 March 2012 at 15:19:15 UTC, H. S. Teoh wrote: > >> Since when is mouse movement a stop-the-world event on Linux? > > > > It's a hardware interrupt. They all work that way. You have > > to give a lot of care to handling them very quickly and > > not letting them stack up (lest the whole system freeze). > > So? It's not stop-the-world. While one core is handling the > interrupt, the other(s) is(are) still running. A stop-the-world GC > would need to block all threads on all cores while running. > > Jerome > > PS: This is nothing restricted to Linux. Windows, MacOS X and the > *BSDs have the same behaviour. [...]
OK, clearly I wasn't understanding what the OP was talking about. It *seemed* to imply that Linux had stop-the-world problems with mouse movement, but this isn't the case. A hardware interrupt is a hardware interrupt. Whatever OS you're using, it's got to stop to handle this somehow. I don't see how else you can do this. When the hardware needs to signal the OS about something, it's gotta do it somehow. And hardware often requires top-priority stop-the-world handling, because it may not be able to wait a few milliseconds before it's handled. It's not like software that generally can afford to wait for a period of time. As for Win95 being unable to keep up with mouse movement... well, to be honest I hated Win95 so much that 90% of the time I was in the DOS prompt anyway, so I didn't even notice this. If it were truly a problem, it's probably a sign of poor hardware interrupt handling (interrupt handler is taking too long to process events). But I haven't seen this myself either. T -- Lottery: tax on the stupid. -- Slashdotter