Thanks... my understanding is that maybeDeferred makes everything async, which means that I then have to make all the calling methods async, etc until the async 'virus' has infected every method :-) Ideally, I'd like to contain the change so that the calling methods can remain synchronous and I don't have to rewrite the callers simply because the implementation of the interface changed. This is sort of option B.
Alternatively, I bite the bullet and convert this method and all its callers (and their callers, recursively) to be async. Just for this one method, I think that means changing: fake::get_info, xenapi::get_info, libvirt::get_info to be async (so callers aren't forced to use maybeDeferred) And then the callers and their callers: monitoring.Instance::fetch_cpu_stats => monitoring.Instance::update => monitoring.InstanceMonitor.updateInstances_ => monitoring.InstanceMonitor.updateInstances service.Instance::info => service.Instance::update_state => ComputeService::adopt_instances (reboot and spawn are already async), VirtualBoxConnection::destroy (reboot and spawn are already async here also) And then because VirtualBoxConnection::destroy has now gone sync->async, then I would need to follow that chain. So I guess >20 functions will need conversion of sync -> async just for this one change. Obviously, before I try submitting that patch, I want to know that this is the right thing to do! Justin On Mon, Aug 2, 2010 at 4:09 PM, Vishvananda Ishaya <[email protected]>wrote: > show details 4:08 PM (0 minutes ago) > I believe Twisted's maybeDefferred is for this purpose. If you use that > for the calls into virt, each provider can used deferreds or not vor the > various methods. We use it from api.py to call the endpoint methods > > Vish > > On Mon, Aug 2, 2010 at 1:19 PM, Justin Santa Barbara > <[email protected]>wrote: > >> I'm hacking on adding VirtualBox support (to allow native Mac development, >> more than as a serious production target). This means adding another virt >> provider (I'm trying without libvirt for now, because libvirt VirtualBox >> support seems a little flaky, and I'm not sure about libvirt on the mac) >> However one of the methods (get_info) is synchronous on the interface, but >> the VirtualBox implementation is asynchronous (it gets its results from >> spawning a process). How do I handle this? >> >> A) Do I change the interface so that the method returns a deferred even in >> the providers that are synchronous? If so, we should just have all >> interfaces return a deferred on all methods, so that the interface doesn't >> expose the implementation. However, this would make everything messy... >> >> B) Should I type-check the result of the call and synchronously wait on >> it if it is deferred? (And can anyone point me at some code that can do a >> sync-wait?) >> >> As an aside, and to borrow from the Wizard of Oz, "Twisted, I've a feeling >> we're not in Python any more". Every method is preceded by >> @defer.inlineCallbacks, return x becomes returnValue(x), and there are >> yields scattered throughout the code based on whether the called method >> returns a deferred or not. Perhaps we can clarify the Twisted vs Eventlet >> discussion: would Eventlet solve this particular problem? >> >> Justin >> >> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~nova >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~nova >> More help : https://help.launchpad.net/ListHelp >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~nova Post to : [email protected] Unsubscribe : https://launchpad.net/~nova More help : https://help.launchpad.net/ListHelp
