Breaking backwards compatiblity

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Mar 10 08:24:16 PST 2012


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


More information about the Digitalmars-d mailing list