[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]