On 05/26/14 17:30, Jiri Denemark wrote: > Currently, we don not acquire any job when removing a device after > DEVICE_DELETED event was received from QEMU. This means that if there is > another API running at the time DEVICE_DELETED is delivered and the API > acquired a job, we may happily change the definition of the domain the > API is working with whenever it unlocks the domain object (e.g., to talk > with its monitor). That said, we have to acquire a job before finishing > device removal to make things safe. However, doing so in the main event > loop would cause a deadlock so we need to move most of the event handler > into a separate thread. > > Another good reason for both acquiring a job and handling the event in a > separate thread is that we currently remove a device backend immediately > after removing its frontend while we should only remove the backend once > we already received DEVICE_DELETED event. That is, we will have to talk > to QEMU monitor from the event handler. > > Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx> > --- > src/qemu/qemu_domain.h | 2 ++ > src/qemu/qemu_driver.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++-- > src/qemu/qemu_process.c | 27 +++++++++++++++++++-------- > 3 files changed, 67 insertions(+), 10 deletions(-) > ACK, Peter
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list