On 12/05/2012 01:05 AM, Mike wrote:
在 2012-12-04二的 17:09 -0500，Chris Evich写道：
On 12/03/2012 09:37 PM, Mike Qiu wrote:
Currently, when try to get the ip address as mutil threads wait to
login to the guest, all threads will call update_db, which need to
lock the db file, this will raise error for lots of the threads.
As all these threads just want to get the ip address of the guest,
These errors should not happen, and it will never change the db_file,
So, no need to call func update_db.
By the way, self._INITIALIZED will be set to true after the network
interface be init.
Signed-off-by: Mike Qiu<[email protected]>
---
virttest/utils_misc.py | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/virttest/utils_misc.py b/virttest/utils_misc.py
index d37cf87..b83b7cd 100644
--- a/virttest/utils_misc.py
+++ b/virttest/utils_misc.py
@@ -1004,9 +1004,6 @@ class DbNet(VMNet):
def __getitem__(self, index_or_name):
# container class attributes are read-only, hook
- # update_db here is only alternative
- if self._INITIALIZED:
- self.update_db()
return super(DbNet, self).__getitem__(index_or_name)
Dang, I wish I put a better comment :( I do remember at the time I
wrote it, it was important to acquiesce the db/dict state before
returning value because we cannot guarantee WHEN new guest might have
networking info. added/deleted. Also the the underlying class storing
these items had a __setitem__ limitation, which I think is what my
comment refers to.
The good news is the underlying storage class was changed recently, so
my original concern over db/dict state consistency may no longer apply.
The concern you raise about lock contention with multiple threads is a
bug since this is a case I was trying to solve for.
Could you describe from higher level what you are seeing? i.e. what
code is trying to get IP address?
It's about the kvm test case vmstop, it just use 10 threads to login
to the guest, and copy file to the guest.
So for each threads need to get the ip address of the guest.
As you now try to fix this problem, I will follow up your steps:)
With your patch above, does the utils_misc_unittest.py run fine?
I'm so sorry that it will fail.
No problem, it's more important you report problem and try to find fix.
Main problem is I made this too complicated :( Thanks for the test
reference, I'll check it out and investigate fix.
--
Chris Evich, RHCA, RHCE, RHCDS, RHCSS
Quality Assurance Engineer
e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
