[libvirt] [PATCH 1/2] virCommandDoAsyncIO: Resolve race

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 621 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130207/ce7d39d2/attachment-0001.sig>