[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 10/22] monitor: allow to use IO thread for pars
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC v2 10/22] monitor: allow to use IO thread for parsing |
Date: |
Thu, 12 Oct 2017 13:35:08 +0100 |
User-agent: |
Mutt/1.9.0 (2017-09-02) |
On Fri, Sep 29, 2017 at 11:38:32AM +0800, Peter Xu wrote:
> For each Monitor, add one field "use_io_thr" to show whether it will be
> using the dedicated monitor IO thread to handle input/output. When set,
> monitor IO parsing work will be offloaded to dedicated monitor IO
> thread, rather than the original main loop thread.
Why make use_io_thr optional? We'd have to maintain and test both code
paths.
> @@ -4135,19 +4139,37 @@ void monitor_init(Chardev *chr, int flags)
> monitor_read_command(mon, 0);
> }
>
> + if (mon->use_io_thr) {
> + /*
> + * When use_io_thr is set, we use the global shared dedicated
> + * IO thread for this monitor to handle input/output.
> + */
> + context = monitor_io_context_get();
> + /* We should have inited globals before reaching here. */
> + assert(context);
> + } else {
> + /* The default main loop, which is the main thread */
> + context = NULL;
> + }
> +
> + /*
> + * Hang the monitor before running it (which is triggered by
s/Hang/Add/
"Hang" isn't used as a verb for adding items to collections. People
would probably think about deadlocking the thread instead :-).
> + * qemu_chr_fe_set_handlers). Otherwise one monitor may run while
> + * find itself not on the mon_list.
> + */
> + qemu_mutex_lock(&monitor_lock);
> + QTAILQ_INSERT_HEAD(&mon_list, mon, entry);
> + qemu_mutex_unlock(&monitor_lock);
- Re: [Qemu-devel] [RFC v2 10/22] monitor: allow to use IO thread for parsing,
Stefan Hajnoczi <=