Package: dbus-python / 1.2.8-3
Patch seriesview the series file
|cross test client Wait until default method timeout for E.patch | (download)||
2 0 + 2 - 0 !
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)||
13 9 + 4 - 0 !
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