GNOME Bugzilla – Bug 577526
Starting and stopping ekiga is too unreliable
Last modified: 2020-06-06 16:30:45 UTC
Starting ekiga works only mostly ok : - the linker makes sure we won't start without what we need, or load a non-applicable plugin - the kickstart scheme makes sure we initialize things in the right order (which is trivial for builtins since we should put them in the right order, but will be pretty useful when things will come as plugins!) - however, that still leaves issues : for example when the video code will initialize its gmconf bridge correctly (this is bug #568606), then it will try to access the devices early -- which is bad because said devices may come from a plugin which won't be ready before much later. Stopping ekiga is much simpler : we just get out of the main loop and let the C++ destructors clean behind us. The problem is that I'm not 100% sure the order in which things occur is good (there are still unexplained crashes...). This situation is pretty annoying : we should do something to get a clearer and safer operation. One of the big hurdle is already reported : the Ekiga::Runtime system is just bad (see bug #557889). I propose to add run/shutdown methods to the Ekiga::Service base class, which will allow more finely controlled startup and shutdown of ekiga. The start method will ensure for example that video preview won't be enabled before all plugins are loaded. And the stop method will make sure each threaded component will properly shut down all threads. In short, ekiga's main function should mostly look like : - kickstart engine - run engine - Ekiga::Runtime::run () - shutdown engine - C++ destructors What do you think about it?
One idea: Adding dependency information: thing T1, when wants to use thing T2, will wait until thing T2 is initialised, which is done through a variable, initially 0, and after initialisation 1. T1 executes: while (! T2.var) sleep (50 ms); I suppose here that T1 and T2 are executed in different threads.
No thread issue in the engine. The piece of code which creates threads, deals with threads and hides them to the rest. The dependancy issues could be managed with weak pointers (that would be an argument for going the boost smart pointers way).
Eugen, notice that the kickstart scheme already makes a part of ekiga refuse to connect to the engine until deps are satisfied!
Ekiga is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273 Ekiga saw its last release 7 years ago. The last code commits were 4 years ago. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.