Lockup / program freeze in new event system

[Maker42]

I have found that triggering Qt events from within Qt event handlers intermittently causes lockups. The lockup is rare, but of course guaranteed to happen when its most critical that it works. :)

All handlers in the new event system should either start a one-shot thread or message a long-lived thread to do things which trigger other events, which is pretty much all actions and/or functions currently.

[birkelbach]

I have not seen any lockups. Can you duplicate this? Do you know which actions are causing the lockup?

[Maker42]

The only time I've been able to replicate this is by having a process that takes a fix.db change event, and changes other DB items in the event handler. Maybe for some reason it's OK with non-DB events. I couldn't duplicate a hang with repeated button clicks.

In any case, keep this in mind if you start seeing unexplained hangs.

[birkelbach]

I'm going to start writing some unit tests for these things. I'll try and torture test it and see if I can replicate the problem.

[e100]

Maybe we should create a watchdog feature that could detect and restart pyefis if it locks up.

The watchdog could work something like this:
A timer thread that increments some fix gateway value once a second
Maybe it would count 1 to 100 then 100 to 1 and just keep repeating.

A separate program would monitor that value checking once a second. If it does not see the value change 3 times in 5 seconds it would kill and restart pyefis.

Maybe the fix gateway should also have such a feature too.

[birkelbach]

I have another project that is similar to FiXGateway that I've been working on and it has a supervising process that can kill and restart children if they misbehave. It would not be terribly difficult to implement such a program. It could then launch both fixgw and pyefis as well as monitor them.

[e100]

Is anyone still seeing lockups?
I've been testing pyefis extensively the last few months and do not recall a single lockup.