On Sun, Feb 17, 2013 at 12:59 AM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 17 February 2013 00:19, Peter Maydell <peter.mayd...@linaro.org> wrote: >> [why doesn't MacOS QEMU exit on ctrl-C?] >> What seems to happen is that the other thread nips in and >> does the sigreturn/sigprocmask/sigaltstack stuff, and >> it's messing with the signal mask for the whole process. >> (dtruss also tell me 0x6f8c53 is the TCG CPU thread.) > > Found it! The culprit is the setjmp/longjmp in cpu-exec.c. > On Linux these don't save and restore the process signal mask > (you use sigsetjmp/siglongjmp for that). However on BSD setjmp > and longjmp do save and restore the process signal mask, so > when we do the longjmp in the CPU thread we end up setting the > mask for every thread to the restrictive mask used by the > CPU thread. Then SIGTERM and SIGINT are blocked for every > thread and have no effect on QEMU. > > So, we can fix this MacOS issue by replacing all our current > setjmp() and longjmp() with sigsetjmp(buf, 0) and siglongjmp() > [which is the POSIX mandated way to say "definitely don't > change the signal mask", avoiding the undefined effect > on the signal mask that plain longjmp has.] (I guess that > might require some compat layer for win32 builds, which > is trivial enough.) > > However, having thought about this I'm now a bit dubious about > the use of longjmp in cpu_resume_from_signal() -- this is > jumping out of a signal handler, so if we do nothing with > the signal mask surely we'll end up running the CPU thread > with that signal blocked when it was not before? I don't know > why this doesn't cause issues on Linux...
Long time ago, QEMU did not use any threads. They were introduced by CONFIG_IOTHREAD which then took over. > > -- PMM