[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread
From: |
Peter Xu |
Subject: |
Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread |
Date: |
Wed, 11 Apr 2018 11:49:54 +0800 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
On Wed, Apr 11, 2018 at 09:45:32AM +0800, Stefan Hajnoczi wrote:
> On Tue, Apr 10, 2018 at 08:49:13PM +0800, Peter Xu wrote:
> > cur_mon was only used in main loop so we don't really need that to be
> > per-thread variable. Now it's possible that we have more than one
> > thread to operate on it. Let's start to let it be per-thread variable.
>
> Trying to understand the reason for this patch:
>
> Are there any users of per-thread cur_mon?
Currently no. But if considering future OOB-capable commands, they
will modify cur_mon in monitor IOThread at least.
>
> or
>
> Does this patch fix a bug?
No; currently we have no bug. But we have encounter the bug when we
start to add more OOB commands.
Here is the problem (Marc-Andre reported this, and I'll try to
summarize): after we have valid OOB commands,
monitor_qmp_dispatch_one() can be run not only in main thread, but
also in monitor iothread. When that happens, both of them (main
thread, and monitor iothread) can be modifying the cur_mon variable at
the same time. [1]
Considering that cur_mon is only used "just like" a stack variable, it
should be perfectly fine we just make it as a per thread variable,
hence this patch.
>
> > In case we'll create threads within a valid cur_mon setup, we'd better
> > let the child threads to inherit the cur_mon from parent thread too. Do
> > that for both posix and win32 threads.
>
> Without actual users I don't like this. It sounds like "let's make it
> global just in case something needs it some day".
>
> It's ugly for QEMU's thread API to know about the monitor - that's a
> layering violation.
Yes, I'm sorry about it. Actually I don't like it too. But that
seems to be an efficient and simple solution to me now. The ideal
solution should be totally removing cur_mon, which is non-trivial.
And for sure we can try to avoid layer violation. For example, we can
have something like qemu_thread_register_variable(pthread_key_t), then
monitor code can register the cur_mon pthread_key to the qemu thread
module. That'll somehow achieve isolation between modules but I'm not
sure whether that would be necessary for now, hence I chose the simple.
>
> If there's a legitimate need I think this patch might be necessary, but
> I don't see enough justification to do this yet.
The problem was described at [1]. Thanks,
--
Peter Xu
- [Qemu-devel] [PATCH 0/2] qemu-thread: allow cur_mon be per thread, Peter Xu, 2018/04/10
- [Qemu-devel] [PATCH 1/2] qemu-thread: always keep the posix wrapper layer, Peter Xu, 2018/04/10
- [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Peter Xu, 2018/04/10
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Eric Blake, 2018/04/10
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Stefan Hajnoczi, 2018/04/10
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread,
Peter Xu <=
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Paolo Bonzini, 2018/04/11
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Peter Xu, 2018/04/11
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Paolo Bonzini, 2018/04/11
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Peter Xu, 2018/04/11
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Eric Blake, 2018/04/11
- Re: [Qemu-devel] [PATCH 2/2] qemu-thread: let cur_mon be per-thread, Peter Xu, 2018/04/12