Restarting input.device?

A forum for general AmigaOS 4.x support questions that are not platform-specific
Locked
Deniil
Posts: 111
Joined: Mon Jul 11, 2011 7:59 pm

Restarting input.device?

Post by Deniil »

A crash in input.device is probably one of the more annoying bugs because it can be pretty much completely harmless, yet it requires a reboot since all input is halted.

How about if the system could detect crashes in input.device and restart it? That would allow the developer to check the Grim Reaper what went wrong and not having to reboot a fully working machine just because it can't receive input anymore.
User avatar
abalaban
Beta Tester
Beta Tester
Posts: 456
Joined: Mon Dec 20, 2010 2:09 pm
Location: France
Contact:

Re: Restarting input.device?

Post by abalaban »

This could be a good idea, but I doubt it will work correctly. What about applications that opened input.device? They are not prepared to this. In fact they wouldn't even notice input.device is crashed and they will probably still try to deal with it, instead of trying to open the new one. For example USB HID devices - depending on how they generate input events - would probably not work because they will still be tied to the crashed device... In case we would want such behavior we would first have to implement some sort of notification so that every application dealing with input.device would know the old one is crashed and it should reopen it to obtain a working one...
Moreover I don't know the inner working of input.device but it's probably using an event stack so you might very well loose all the events still in the stack, which can lead to strange kind of things or even bad things.
AmigaOne X1000 running AOS 4 beta
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
Deniil
Posts: 111
Joined: Mon Jul 11, 2011 7:59 pm

Re: Restarting input.device?

Post by Deniil »

It could be an internal thing in the input.device task, like a watchdog task. So instead of starting a completely new separate input.device unrelated to the first it could just take over the existing input event stream that apps and the system has hooked into to send and read events. Basically a standby copy of itself with a watchdog feature.

I mean, the part that crashes input.device is when it executed a malfunctioning interrupt that some app hooked up. It could even be smart enough to make a note when it executing an inputerrupt saying "now I'm running this code, if the watchdog catches me you know what interrupt to unlink before restarting me, ok?".
Like:

Code: Select all

processInput(event) {
  while(inputChain) {
    nowExecuting=inputChain->interrupt;
    event=execute(inputChain->interrupt, event)
    nowExecuting=NULL
    next(inputChain)
  }
}

watchdogTimeout() {
  if(nowExecuting) unlink(nowExecuting, inputChain)
  restartInputDevice(inputChain)
}
User avatar
ssolie
Beta Tester
Beta Tester
Posts: 1010
Joined: Mon Dec 20, 2010 8:51 pm
Location: Canada
Contact:

Re: Restarting input.device?

Post by ssolie »

See the LAYOUT_DeferLayout tag which already supports offloading from input.device in some circumstances.

We would like to move towards moving more off of the input.device context but of course you have to consider all the applications which currently rely on the assumption they are running on input.device and there is only one instance.

In any case, such changes are already being considered at the OS level.
ExecSG Team Lead
Locked