| 2012-09-27 16:42:33 |
Rafał Cieślak |
description |
If the daemon is already running when the viewer starts, everything works correctly. But if it is not, the viewer shows confusing behavior.
* It displays message 'Failed to connect to the daemon', which may be misleading for users (and may be a source of unwanted bug reports)
* It starts the daemon, but not immediately - it gets launched several seconds later.
* At first it says it failed to kill the daemon, then waits some another time, and only then it launches it successfully.
Probably this bug may affect daemon launcher too.
It may be a good idea to include a 'Starting daemon' message in case it is not possible to get it started immediately. |
Steps to reproduce:
1. Use a HDD drive. The slower it is, the greater chances you'll be affected.
2. Disable daemon automatic startup on login.
3. Log off and back in.
4. Start the viewer. (If you start the daemon first, run the viewer for second time since login, or if the daemon has been running since last login you will not be affected)
What should happen:
1. The viewer should display status message "Starting the daemon..."
2. After a second, trophies should be displayed.
What happens instead:
1. The viewer displays "Starting the daemon" message, and waits in this state for a second or few.
2. For next 5-10 seconds, the viewer displays "Failed to connect to daemon"
3. Afterwards it displays "Starting the daemon" again, and everything is back to normal.
Why this is wrong:
The 'Failed to connect to daemon' message confuses users, and increases viewer's initiation time.
Why this happens:
Loading twistd, daemon and initializing it (which reads accoms colelctions) takes some time on drives which are not too fast. If during this time the viewer tries to connect to the daemon, it will fail indeed. When the daemon is started on login, it will initiate before one launches the viewer. If the drive is fast enough (e.g. SSD) this bug does not appear. If the daemon is started for the second time in one login session, it takes much much less time to start (I guess it's some magic caching) and thus this bug is not present in such cases.
Ideas on how this can be solved:
The simplest fix is to increase waiting time, but that increases the time the viewer needs to start in all cases.
A more clever fix would be to wait for the "accomplishments-daemon --start" to return, and then connect to the daemon via dbus. Currently we blindly run "accomplishments-daemon --start &" and try connecting after some time. Of course the launched command may not block viewer's code execution, as that would freeze UI. Therefore we need a clever way to be notified when this command returns. |
|
