From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39876) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyvfZ-00080L-MT for qemu-devel@nongnu.org; Mon, 15 Jul 2013 23:11:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyvfY-0005rM-Rg for qemu-devel@nongnu.org; Mon, 15 Jul 2013 23:11:17 -0400 Received: from mail-wg0-x235.google.com ([2a00:1450:400c:c00::235]:52046) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyvZp-0004Qs-AT for qemu-devel@nongnu.org; Mon, 15 Jul 2013 23:05:21 -0400 Received: by mail-wg0-f53.google.com with SMTP id y10so128958wgg.8 for ; Mon, 15 Jul 2013 20:05:20 -0700 (PDT) Date: Tue, 16 Jul 2013 11:05:11 +0800 From: Stefan Hajnoczi Message-ID: <20130716030511.GF32278@stefanha-thinkpad.redhat.com> References: <1373917279-15360-1-git-send-email-borntraeger@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1373917279-15360-1-git-send-email-borntraeger@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH 02/12] trace+libvirt: start trace processing thread in final child process List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger Cc: aliguori@us.ibm.com, =?iso-8859-1?Q?Llu=EDs?= , Michael Mueller , qemu-devel@nongnu.org On Mon, Jul 15, 2013 at 09:41:19PM +0200, Christian Borntraeger wrote: > When running with trace backend e.g. "simple" the writer thread needs to be > implemented in the same process context as the trace points that will be > processed. Under libvirtd control, qemu gets first started in daemonized > mode to privide its capabilities. Creating the writer thread in the initial > process context then leads to a dead lock because the thread gets termined > together with the initial parent. (-daemonize) This results in > stale qemu processes. > Fix this by deferring trace initialization. I don't think this works since trace events will fill up trace_buf[] and eventually invoke flush_trace_file(). At that point we use trace_available_cond and trace_empty_cond, which may be NULL in Glib <2.31.0. Perhaps this can be made safe by checking trace_writeout_enabled. It will be false before the backend has been initialized. Stefan