lp://qastaging/~zyga/checkbox/fix-1318504

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp://qastaging/checkbox at revision 3032

Daniel Manrique (community): Approve on 2014-05-23

Diff: 224 lines (+81/-92)

1 file modified

checkbox-ng/checkbox_ng/service.py (+81/-92)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #1318504: [checkbox-gui] org.freedesktop.DBus.Error.NoReply

Critical

Invalid

Link a bug report

Related blueprints

3031. By Zygmunt Krynicki on 2014-05-23

checkbox-ng:service: remove useless locking

This patch removes all locks used by checkbox-ng's service code.

First some background about concurrent.futures._base.Future's
add_done_callback() method:

 | add_done_callback(self, fn)
 | Attaches a callable that will be called when the future finishes.
 |
 | Args:
 | fn: A callable that will be called with this future as its only
 | argument when the future completes or is cancelled. The callable
 | will always be called by a thread in the same process in which
 | it was added. If the future has already completed or been
 | cancelled then the callable will be called immediately. These
 | callables are called in the order that they were added.

The *essential* fact is that the thread eventually calls the callback is
always the same thread that was used to register the method.

Since we have two threads here (basically, there are more but here only
two will interact):

1) The thread running almost all the python code in service.py
   and elsewhere. This is where we handle requests sent via DBus
2) The thread that just blocks on the job runner to finish.
   This thread is created indirectly with multiprocessing used by
   the highlevel module.

The original intent of _result_lock was, to quote:

    # A lock that protects access to :ivar:`_result` and
    # :ivar:`_result_future` from concurrent access from the thread that is
    # executing Future callback which we register, the
    # :meth:`_result_ready()`

Which is entirely bogus as there are no threads like that. Had I known
there was the callback guarantee I would never had added that lock in
the first place.

Fixes: https://bugs.launchpad.net/plainbox/+bug/1318504

Signed-off-by: Zygmunt Krynicki <email address hidden>

3030. By Launchpad Translations on behalf of checkbox-dev on 2014-05-23

Launchpad automatic translations update.

3029. By Sylvain Pineau on 2014-05-22

"automatic merge by tarmac [r=zkrynicki][bug=1315337][author=sylvain-pineau]"

3028. By Daniel Manrique on 2014-05-22

"tarmac-verify: fix setting of KEEP_DATA environment variable.

Without this fix, we use --keep-data all the time, making lxc much slower as it uses actual disk storage instead of blazing-fast tmpfs on ram. [r=roadmr][bug=][author=roadmr]"

3027. By Zygmunt Krynicki on 2014-05-22

"automatic merge by tarmac [r=roadmr][bug=][author=zkrynicki]"

3026. By Zygmunt Krynicki on 2014-05-22

"automatic merge by tarmac [r=roadmr][bug=1302388][author=zkrynicki]"

3025. By Zygmunt Krynicki on 2014-05-22

"automatic merge by tarmac [r=roadmr][bug=][author=zkrynicki]"

3024. By Po-Hsu Lin on 2014-05-22

"automatic merge by tarmac [r=roadmr][bug=1321356][author=cypressyew]"

3023. By Zygmunt Krynicki on 2014-05-22

"automatic merge by tarmac [r=roadmr][bug=][author=zkrynicki]"

3022. By Po-Hsu Lin on 2014-05-22

"automatic merge by tarmac [r=roadmr][bug=1321995][author=cypressyew]"