From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39331) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzHAH-0004Gf-O3 for qemu-devel@nongnu.org; Tue, 16 Jul 2013 22:08:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UzHAG-0007pW-PH for qemu-devel@nongnu.org; Tue, 16 Jul 2013 22:08:25 -0400 Received: from mail-wg0-x231.google.com ([2a00:1450:400c:c00::231]:59620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UzHAG-0007pP-JZ for qemu-devel@nongnu.org; Tue, 16 Jul 2013 22:08:24 -0400 Received: by mail-wg0-f49.google.com with SMTP id a12so1229742wgh.4 for ; Tue, 16 Jul 2013 19:08:24 -0700 (PDT) Date: Wed, 17 Jul 2013 10:08:15 +0800 From: Stefan Hajnoczi Message-ID: <20130717020815.GC26311@stefanha-thinkpad.redhat.com> References: <1373917279-15360-1-git-send-email-borntraeger@de.ibm.com> <20130716030511.GF32278@stefanha-thinkpad.redhat.com> <20130716141728.787f6b2b@bee> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130716141728.787f6b2b@bee> 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: Michael Mueller Cc: Christian Borntraeger , aliguori@us.ibm.com, qemu-devel@nongnu.org, =?iso-8859-1?Q?Llu=EDs?= On Tue, Jul 16, 2013 at 02:17:28PM +0200, Michael Mueller wrote: > On Tue, 16 Jul 2013 11:05:11 +0800 > Stefan Hajnoczi wrote: > > > 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 > > > > You mean something like this. I'll give it a try: > > --- > trace/simple.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > --- a/trace/simple.c > +++ b/trace/simple.c > @@ -53,7 +53,7 @@ static GCond *trace_empty_cond; > #endif > > static bool trace_available; > -static bool trace_writeout_enabled; > +static bool trace_writeout_enabled = false; static bool is automatically initialized to false. > enum { > TRACE_BUF_LEN = 4096 * 64, > @@ -427,5 +427,6 @@ bool trace_backend_init(const char *even > atexit(st_flush_trace_buffer); > trace_backend_init_events(events); > st_set_trace_file(file); > + trace_writeout_enabled = false; I was thinking along the lines of trace_record_finish() not calling flush_trace_file() if trace_writeout_enabled is false. Stefan