It happened again. I suspect that it may be a matter of ordering of decorators: RegionAdvertisingService.prepare is decorated as @synchronous, and *then* as taking two locks.
Given decorators' "wrapping" behaviour, which reverses the order of entrance, I understand that to mean: "grab these two locks, then run this function synchronously." Which would mean that if the lock weren't available at the time of the call, or if either attempt to grab a lock yielded to the reactor for whatever reason, the function could still run asynchronously from the caller's perspective. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1308069 Title: test_prepare_holds_startup_lock() fails spuriously To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1308069/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
