Re: Der mouse.

[nick@nsis.cl.nec.co.jp (Gavin Thomas Nicol) writes:]

>Actually, I noticed that with the interrupt driven system, it can
>really bog down the system if you do a lot of work in the interrupt
>handler. Do tasks handling interrupts get extra priority?

No, they are setrun in exactly the same way as receiving a message.
I suspect that you were just using a fair fraction of the 386sx's
horsepower just switching into the interrupt task, doing some work,
and returning, only to be called again after very little more time.
If you *really* want to know how bad it gets, you get m_arg (I think
it's m_arg, maybe m_arg1) set to the number of interrupts which have
been registered before you received your M_ISR message.

There *is* a fairness problem with CPU-heavy processes. I've seen my
system bug down badly when I have a runaway server, for instance. I've
just never hunted it down and exterminated it. There used to be a bug
where it would *never* preempt; I fixed that, but obviously there's
more to be done.

You realize that typing ^Z enters the kernel debugger, right? Well,
you ported your own keyboard driver, so obviously you do. Anyway,
without preemption I could never drop into the kernel debugger to
see who was running endlessly. :-(

>I'll have a look into the MGR and Linux sources for ideas on how to
>handle the IBM mouse. Like you said, the code looks simple enough.

Yes, what I saw in MGR was just a handful of lines to interpret the
whole mouse state.

                                        Andy
Received on Wed Oct 27 16:42:28 1993