Re: [PATCH 2/4] docs: Lift restriction on running API from the event loop thread
On Mon, 2021-03-01 at 12:49 +0100, Michal Privoznik wrote: > +++ b/docs/drvqemu.html.in > @@ -158,8 +158,10 @@ qemu+ssh://r...@example.com/system (remote access, SSH > tunnelled) >in mind, applications must NEVER invoke API >calls from the event loop thread itself, only other threads. >Not following this rule will lead to deadlocks in the API. > - This restriction is intended to be lifted in a future release > - of libvirt, once QMP processing moves to a dedicated thread. > + This restriction was lifted starting from 6.2.0 release, when > + QMP processing moved to a dedicated thread. However, it is > + important to let the event loop run after each API call, even > + the ones made from the vent loop thread itself. s/ vent/ event/g Reviewed-by: Andrea Bolognani -- Andrea Bolognani / Red Hat / Virtualization
Re: [PATCH 2/4] docs: Lift restriction on running API from the event loop thread
On 3/1/21 5:49 AM, Michal Privoznik wrote: > Since v6.2.0-rc1~238 (and friends) QMP processing was moved to a > per-domain thread. Therefore, it is now safe to call APIs from > the event loop thread (e.g. just like qemu shim is doing in > qemuShimEventLoop(). However, it is still important to let the > event loop run after each API call (obviously). > > Signed-off-by: Michal Privoznik > --- > docs/drvqemu.html.in | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/docs/drvqemu.html.in b/docs/drvqemu.html.in > index 31d3fee213..3cdd04aa1e 100644 > --- a/docs/drvqemu.html.in > +++ b/docs/drvqemu.html.in > @@ -158,8 +158,10 @@ qemu+ssh://r...@example.com/system (remote access, SSH > tunnelled) >in mind, applications must NEVER invoke API >calls from the event loop thread itself, only other threads. >Not following this rule will lead to deadlocks in the API. > - This restriction is intended to be lifted in a future release > - of libvirt, once QMP processing moves to a dedicated thread. > + This restriction was lifted starting from 6.2.0 release, when > + QMP processing moved to a dedicated thread. However, it is > + important to let the event loop run after each API call, even > + the ones made from the vent loop thread itself. event loop > > > Driver security architecture > -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
[PATCH 2/4] docs: Lift restriction on running API from the event loop thread
Since v6.2.0-rc1~238 (and friends) QMP processing was moved to a per-domain thread. Therefore, it is now safe to call APIs from the event loop thread (e.g. just like qemu shim is doing in qemuShimEventLoop(). However, it is still important to let the event loop run after each API call (obviously). Signed-off-by: Michal Privoznik --- docs/drvqemu.html.in | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/drvqemu.html.in b/docs/drvqemu.html.in index 31d3fee213..3cdd04aa1e 100644 --- a/docs/drvqemu.html.in +++ b/docs/drvqemu.html.in @@ -158,8 +158,10 @@ qemu+ssh://r...@example.com/system (remote access, SSH tunnelled) in mind, applications must NEVER invoke API calls from the event loop thread itself, only other threads. Not following this rule will lead to deadlocks in the API. - This restriction is intended to be lifted in a future release - of libvirt, once QMP processing moves to a dedicated thread. + This restriction was lifted starting from 6.2.0 release, when + QMP processing moved to a dedicated thread. However, it is + important to let the event loop run after each API call, even + the ones made from the vent loop thread itself. Driver security architecture -- 2.26.2
