On 02/07/2013 08:37 AM, Michal Privoznik wrote: >> The async I/O code in virCommand was supposed to be about >> simplifying life - but the requiring the callers to do all >> this mutex locking/unlocking seems to have made things worse >> than they were before we had async I/O code IMHO. I'm half >> inclined to say we should just revert the whole lot. >> >> Daniel >> > > I agree. The other solution that has came up to my mind is just to spawn > virCommandProcessIO (which is doing its own poll()) in a separate thread > and hence we don't need to require the unlock. virCommandWait would just > join the thread then. However, I am not so comfortable with spawning > threads around with no real reason. Making life simpler for the caller is a real reason in my mind - having a dedicated thread for async IO instead of forcing the caller to integrate async IO into its own event loop doesn't sound all that bad. Would you mind writing up that patch, if only so we can compare the two approaches? -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list