On 24 July 2015 at 11:12, Paolo Bonzini <[email protected]> wrote: > aio_notify can be optimized away, and in fact almost always will. However, > qemu_notify_event is used in places where this is incorrect---most notably, > when handling SIGTERM. When aio_notify is optimized away, it is possible that > QEMU enters a blocking ppoll immediately afterwards and stays there, without > reaching main_loop_should_exit(). > > Fix this by using a bottom half. The bottom half can be optimized too, but > it will cause the ppoll not to block. The hang is thus avoided. > > Reported-by: Peter Maydell <[email protected]> > Signed-off-by: Paolo Bonzini <[email protected]> > --- > main-loop.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/main-loop.c b/main-loop.c > index 82875a4..9d93478 100644 > --- a/main-loop.c > +++ b/main-loop.c > @@ -114,6 +114,11 @@ static int qemu_signal_init(void) > #endif > > static AioContext *qemu_aio_context; > +static QEMUBH *qemu_notify_bh; > + > +static void notify_event_cb(void *opaque) > +{ > +}
Could we have a comment to explain why an empty callback is an interesting thing to run, please? I can sort of deduce from the commit message that the purpose of this apparently useless thing is just to provoke the main loop into leaving ppoll() and checking whatever condition it needs to, but it wouldn't be very clear to me just from the code... thanks -- PMM
