Some request can be missed in racy calls

[Didier Roche-Tolomelli]

If you request a dbus call when the service is going to shutdown, you can miss some incoming request in ubuntu sso.

Here is a test file:
1. bzr branch lp:oneconf
2. cd oneconf/oneconf/networksync
3. python ssohandler.py

The included test simulate a first request, and then a second request in a 10 seconds timeout (as if your network disconnected/reconnected as we are making request one network reconnect).
What I get 50% of the time is:

$ python ssohandler.py
DEBUG:__main__:look for credential
DEBUG:__main__:credential found
dbus.Dictionary({dbus.String(u'consumer_secret'): xxxx}, signature=dbus.Signature('ss'))
DEBUG:__main__:look for credential

and no signal callback the second time (it's clearly racy, sometimes I can have it). Seems to be because my timeout is exactly the same amount of time of the sso service one, however it accepted the request, which it shouldn't have done.

Server logs are:
2011-06-23 15:41:43,269:269.972085953 - ubuntu-sso-login - INFO - Starting Ubuntu SSO login manager for bus 'com.ubuntu.sso'.
2011-06-23 15:41:43,272:272.376060486 - ubuntu_sso.account - INFO - Created a new SSO access layer for service url 'https://login.ubuntu.com/api/1.0'
2011-06-23 15:41:43,370:370.063066483 - ubuntu_sso.credentials - INFO - find_credentials: self.app_name "Ubuntu Software Center", result is {}? False
2011-06-23 15:41:43,370:370.434045792 - ubuntu_sso.main - INFO - CredentialsManagement: emitting CredentialsFound with app_name "Ubuntu Software Center".
2011-06-23 15:41:53,381:381.268024445 - ubuntu_sso.main - INFO - Shutting down, calling <built-in function main_quit>.

No input of the second request.