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
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)