Package: dbus-python / 1.2.8-3

Metadata

Package Version Patches format
dbus-python 1.2.8-3 3.0 (quilt)

Patch series

view the series file
Patch File delta Description
cross test client Wait until default method timeout for E.patch | (download)

test/cross-test-client.py | 2 0 + 2 - 0 !
1 file changed, 2 deletions(-)

 cross-test-client: wait until default method timeout for exit()

On a slow machine under load, communication might legitimately take time.
After the default method-call timeout (25 seconds) we'll go into
quit_error_handler() and exit anyway.

Bug-Debian: https://bugs.debian.org/898158
cross test server Avoid a race condition in the client.patch | (download)

test/cross-test-server.py | 13 9 + 4 - 0 !
1 file changed, 9 insertions(+), 4 deletions(-)

 cross-test-server: avoid a race condition in the client

There is a race condition here between these chains of events, which as
far as I can tell has existed for at least 10 years:

* server receives Tests.Trigger() and schedules SignalTests.Triggered
* server returns to main loop
* server emits SignalTests.Triggered
* client receives SignalTests.Triggered

and

* server receives Tests.Trigger() and replies with success
* client receives success and emits SignalTests.Trigger
* server receives SignalTests.Trigger and calls CallbackTests.Response()
* client receives CallbackTests.Response() and calls Tests.Exit()
* server receives Tests.Exit() and replies with success
* client quits its main loop

If we don't reply to Tests.Trigger() until after the SignalTests.Triggered
signal has been sent, because the client called Tests.Trigger()
asynchronously, messages are not re-ordered and the reply arrives after
the signal; so the whole chain of events leading up to
"client receives SignalTests.Triggered" happens before
"client receives success and emits SignalTests.Trigger" and there is
no race condition.

Bug-Debian: https://bugs.debian.org/898158