On 2015/4/24 1:14, Michal Privoznik wrote:
As discussed here:
https://www.redhat.com/archives/libvir-list/2015-April/msg01135.html
Michal Privoznik (5):
virDomainObjListAddLocked: s/false/NULL/ for @oldDef
virDomainObjListNew: Use virObjectFreeHashData
Introduce virDomainObjEndAPI
virDomainObjListFindByName: Return referenced object
virDomainObjList: Introduce yet another hash table
src/bhyve/bhyve_driver.c | 3 +-
src/conf/domain_conf.c | 83 +++++++++++++++++++++++------------
src/conf/domain_conf.h | 2 +
src/libvirt_private.syms | 1 +
src/libxl/libxl_driver.c | 10 ++---
src/lxc/lxc_driver.c | 3 +-
src/openvz/openvz_driver.c | 11 +++--
src/parallels/parallels_driver.c | 3 +-
src/qemu/qemu_domain.c | 7 +--
src/qemu/qemu_driver.c | 14 ++----
src/test/test_driver.c | 93 +++++++++++++---------------------------
src/uml/uml_driver.c | 15 +++----
12 files changed, 110 insertions(+), 135 deletions(-)
BTW, we just dealt with virDomainObjListFindByName() here, without caring about
virDomainObjListFindByID().
virDomainObjListFindByID() is now called by umlDomainDestroyFlags() and
umlDomainShutdownFlags(),
if we simultaneously shutdown multiple vms on hypervisor UML, then similar problem comes
out:
some guest maybe unable to shutdown immediately, until other guests get shutoff, and even
'virsh list' blocks.
so, shall we:
1 don't take such problem as a problem
2 use virDomainObjListFindByName() instead of virDomainObjListFindByID() there.
3 add a third hash table for domid
If we use virDomainObjListFindByName() there, and forbids developers from using **ByID(),
it seems unacceptable for
any developers.
If we add a third hash table, it may become not easy to maintain the high-complexity
codes. Is there a better solution other
than adding more hash tables?