https://bugzilla.redhat.com/show_bug.cgi?id=866524
The two patches are to fix the same bug in different method,
1/2 is suggested by Daniel in the bug. 2/2 is an alternative
way to fix it by locking the whole virConnect object.
The reason to post 2/2 is that I think 1/2 doesn't fix
the root problem, though I believe it must fix the bug. A
thread can get the lock before/during doRemoteClose, and it
might drop into the similar situation, though it's not the
case now because remoteClientCloseFunc doesn't do changes
which can cause race for the later doRemoteClose. However,
I'm not sure if locking the whole object will cause some
unexpected result.
Osier Yang (2):
remote: Avoid the thread race condition
Lock the whole virConnect Object when disposing to avoid the thread
race
src/datatypes.c | 4 ++--
src/remote/remote_driver.c | 4 ++++
2 files changed, 6 insertions(+), 2 deletions(-)
Regards,
Osier