From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50848) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuN2F-0005tZ-U9 for qemu-devel@nongnu.org; Tue, 10 Jun 2014 10:28:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WuN28-0001bC-6a for qemu-devel@nongnu.org; Tue, 10 Jun 2014 10:28:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WuN27-0001b7-TZ for qemu-devel@nongnu.org; Tue, 10 Jun 2014 10:28:16 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5AESE4t006526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 10 Jun 2014 10:28:15 -0400 Date: Tue, 10 Jun 2014 10:28:12 -0400 From: Luiz Capitulino Message-ID: <20140610102812.4d783438@redhat.com> In-Reply-To: <5397151D.1050700@redhat.com> References: <1401813551-6667-1-git-send-email-pbonzini@redhat.com> <1401813551-6667-6-git-send-email-pbonzini@redhat.com> <20140610101018.34c62092@redhat.com> <5397151D.1050700@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 5/6] monitor: protect outbuf with mutex List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, famz@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, kraxel@redhat.com On Tue, 10 Jun 2014 16:24:29 +0200 Paolo Bonzini wrote: > Il 10/06/2014 16:10, Luiz Capitulino ha scritto: > >> > + qemu_mutex_lock(&hmp.out_lock); > >> > if (qstring_get_length(hmp.outbuf) > 0) { > >> > output = g_strdup(qstring_get_str(hmp.outbuf)); > >> > } else { > >> > output = g_strdup(""); > >> > } > >> > + qemu_mutex_unlock(&hmp.out_lock); > > Are you sure we need to lock/unlock in this function? hmp is allocated > > in the stack. > > > > No, we don't but it was more obvious to me this way (and looking at it > again, I'm pretty sure that some static analyzer would complain without > these). Fine, I'm OK with that.