[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] qemu-nbd vs 'simple' trace backend vs iote
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-block] [Qemu-devel] qemu-nbd vs 'simple' trace backend vs iotest 147 |
Date: |
Fri, 13 Jul 2018 14:53:46 +0100 |
User-agent: |
Mutt/1.10.0 (2018-05-17) |
On Fri, Jul 13, 2018 at 08:40:19AM +0200, Paolo Bonzini wrote:
> On 12/07/2018 18:30, Stefan Hajnoczi wrote:
> > On Wed, Jul 11, 2018 at 03:33:21PM +0200, Cornelia Huck wrote:
> >> The other qemu-nbds (the inet and the unix socket ones from the first
> >> run, the second inet one from the second run) have a single thread with
> >> the same backtrace I posted above.
> >
> > We just discussed this on IRC, but for the record:
> >
> > qemu-nbd --fork will fork the process after the simpletrace write-out
> > thread has been spawned. The child process lacks this thread (due to
> > how fork(2) handles multithreading). Either qemu-nbd needs to
> > initialize tracing later (but that means we cannot trace early init) or
> > simpletrace needs a way to respawn the write-out thread.
>
> You can use pthread_atfork for this.
Thanks. The man page says:
The intent of pthread_atfork() was to provide a mechanism
whereby the application (or a library) could ensure that mutexes and
other process and thread state would be restored to a consistent
state. In practice, this task is generally too difficult to be
practicable.
Challenge accepted!
Stefan
signature.asc
Description: PGP signature