OSDev.org

I have no idea why this happens, but I need a way to prevent it. It is rare in that it happens, but here goes the event:

The OS has too many tasks running and demanding execution at the same time.
User input devices slow down.
GUI freezes/updates slowly.
The major tasks are done.
THE INPUT DEVICES START REPLAYING.

By the last step I mean, when the pc unfreezes, the mouse/keyboard start moving/writing. This is a baaad thing in some cases.

Last time I remember, a 3d program had to do a lot of math. My mouse slowed. So I waved it around hoping to stop the panic. After the math was done, the pc and mouse went back to normal speed, but now I had to wait for the mouse to finish moving. Is it a buffer?

yes. This definitely sounds like your mouse events, etc. have been reported to the graphical server (through files like /dev/mouse) which hasn't the processing time needed to execute them, thus they remain pending until X become active anew.

Under windows you'd rather have small beeps saying the events were "silently" dropped (well, for win9x at least)

This seems to prove that everything is a file is not a fine policy for user input: streams like /dev/mouse should have things like discarding of events if they haven't been read in a given time interval from their enqueueing.

Tux wrote:After the math was done, the pc and mouse went back to normal speed, but now I had to wait for the mouse to finish moving. Is it a buffer?

This is bad. What OS are you using? The mouse driver should stop queueing events after the buffer is filled, or it should start discarding old events and only keeping the latest events.

Ideally the pointer would keep moving even if the handler isn't available to handle the mouse. This can be done either by putting the pointer handler at a high priority (so it will move the pointer even if some other thread has the CPU) or by having the kernel itself handle the pointer.

the more: device drivers and gui services shall have a priority higher than processes doing math which spin around the cpu in round robin manner. So, you should achieve a good responsiveness of the system.

mouse events ... why not stuff them in a kind of circular buffer which has a limited capability first... and have the mouse driver fetch them off that queue and process/dispatch them further?

i'm unsure whether your technique of handling mouse event would be appropriate, especially if mouse events are "moved (+x,+y)" like.

[*] it's fairly easy to have interrupt-priority software that will translate mouse movements into cursor coordinates. Your GUI (whatever its priority is) will then always have the "correct" cursor location, even if the cursor update may occur 3 times a minute.

[*] important events like cursor clicks should rather be dropped than erasing previous ones: it's always possible for the user to re-do a dropped sequence while having the start of the click sequence erased may lead to unpredictable results.

[*] there should be a magic key sequence that would force the system to freeze everything but a minimal user interface that could be used to kill/unfreeze processes selectively, or to type something that should be send at once to a box (by passing the 'response time' problem of a heavily loaded system)

@pype:
I'd split the task up in two or more: the mouse int handler (bottom half) and the mouse driver task (top half). Since the mouse driver task gets a wake up as soon as mouse events are present to be processed/dispatched, seldom a mouse event will be missed, and even if, the only thing that would happen is a jumpy mouse pointer, but this I consider a very unnecessary thing which just won't be happen given the proper design of the drivers ...

and No, I will not have programs "read" at a /dev/mouse file, as for this kind of device, the file approach is purest nonsense. there is no end of file in a mouse input. there arrive packets and they have to be processed by a dedicated chain of tasks/processes, which talk together exchanging a protocol nor do I have programs 'read' at a terminal file for it's walkint thrice around the church before going to prayer doing so...

tack sa mycket

I would give gui and input drivers high prioority. 1-10 10 being most active 1 being idle gui and input should be 8. Not too high and certainly higher than most apps.

maybe even 9 or 10 and only allow user apps to get to 8 or 9? i think it would work well.