[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type |
Date: |
Mon, 27 May 2019 10:18:42 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) |
Marc-André Lureau <address@hidden> writes:
> Hi
>
> On Thu, May 23, 2019 at 9:52 AM Markus Armbruster <address@hidden> wrote:
>> I'm not sure how asynchronous commands could support reconnect and
>> resume.
>
> The same way as current commands, including job commands.
Consider the following scenario: a management application such as
libvirt starts a long-running task with the intent to monitor it until
it finishes. Half-way through, the management application needs to
disconnect and reconnect for some reason (systemctl restart, or crash &
recover, or whatever).
If the long-running task is a job, the management application can resume
after reconnect: the job's ID is as valid as it was before, and the
commands to query and control the job work as before.
What if it's and asynchronous command?
>> >> I'm ignoring "etc" unless you expand it into something specific.
>> >>
>> >> I'm also not taking the "weird" bait :)
>> >> > The following series implements an async command solution instead. By
>> >> > introducing a session context and a command return handler, it can:
>> >> > - defer the return, allowing the mainloop to reenter
>> >> > - return only to the caller (instead of broadcast events for reply)
>> >> > - optionnally allow cancellation when the client is gone
>> >> > - track on-going qapi command(s) per client/session
>> >> >
>> >> > and without introduction of new QMP APIs or client visible change.
>> >>
>> >> What do async commands provide that jobs lack?
>> >>
>> >> Why do we want both?
>> >
>> > They are different things, last we discussed it: jobs are geared
>> > toward block device operations,
>>
>> Historical accident. We've discussed using them for non-blocky stuff,
>> such as migration. Of course, discussions are cheap, code is what
>> counts.
>
> Using job API means providing new (& more complex) APIs to client.
>
> The screendump fix here doesn't need new API, it needs new internal
> dispatch of QMP commands: the purpose of this series.
>
> Whenever we can solve things on qemu side, I would rather not
> deprecate current API.
Making a synchronous command asynchronous definitely changes API.
You could still argue the change is easier to handle for QMP clients
than a replacement by a job.
[...]
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Marc-André Lureau, 2019/05/17
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Markus Armbruster, 2019/05/21
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Marc-André Lureau, 2019/05/21
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Markus Armbruster, 2019/05/23
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Marc-André Lureau, 2019/05/25
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type,
Markus Armbruster <=
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Gerd Hoffmann, 2019/05/27
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Markus Armbruster, 2019/05/27
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Marc-André Lureau, 2019/05/27
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Gerd Hoffmann, 2019/05/28
- Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, Kevin Wolf, 2019/05/31
Re: [Qemu-devel] [PATCH v4 00/20] monitor: add asynchronous command type, John Snow, 2019/05/21