Peter Xu <pet...@redhat.com> writes: > In the future the monitor iothread may be accessing the cur_mon as > well (via monitor_qmp_dispatch_one()). Before we introduce a real > Out-Of-Band command,
Uh, inhowfar are the commands marked allow-oob: true now not real? These are migrate-recover, migrate-pause, x-oob-test. Aside: having x-oob-test in QEMU proper is awful. Is there really no way around it? > let's convert the cur_mon variable to be a > per-thread variable to make sure there won't be a race between threads. > > Note that thread variables are not initialized to a valid value when new > thread is created. However for our case we don't need to set it up, > since the cur_mon variable is only used in such a pattern: > > old_mon = cur_mon; > cur_mon = xxx; > (do something, read cur_mon if necessary in the stack) > cur_mon = old_mon; > > It plays a role as stack variable, so no need to be initialized at all. > We only need to make sure the variable won't be changed unexpectedly by > other threads. Do we plan to keep switching cur_mon forever? Or do we intend to work towards a 1:1 association between Monitor struct and monitor thread? Even if we want the latter, I'm okay with this patch as an intermediate step. > Signed-off-by: Peter Xu <pet...@redhat.com>
