Shireesh Anjal has posted comments on this change. Change subject: gluster: Fixed deadlock in nested command execution ......................................................................
Patch Set 1: Thanks Omer. I looked at RunVmCommand, and what I understand is: - Create a sub-step for the nested command - Create a new ExecutionContext and set this sub-step in it - Create a new CommandContext, passing the newly created execution context, and the lock from current command (getLock()) - Pass this command context as last argument to Backend#runInternalAction() - Since runInternalAction() would have released the lock we passed to it, set the lock to null, so that the current command doesn't try to release it again. The last part looks a bit hacky to me. I feel the approach of "nested command need not acquire (and hence need not release) the lock if it's already acquired by outer command" is better/cleaner. Do let me know what you think.. -- To view, visit http://gerrit.ovirt.org/10448 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Id080ad6ac3587ab9c3443cb83969783955dfb082 Gerrit-PatchSet: 1 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Shireesh Anjal <san...@redhat.com> Gerrit-Reviewer: Kanagaraj M <kmayi...@redhat.com> Gerrit-Reviewer: Michael Kublin <mkub...@redhat.com> Gerrit-Reviewer: Omer Frenkel <ofren...@redhat.com> Gerrit-Reviewer: Shireesh Anjal <san...@redhat.com> _______________________________________________ Engine-patches mailing list Engine-patches@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-patches
