On 4 December 2012 11:21, Janne Karhunen <955...@bugs.launchpad.net> wrote: > And what would break if we make poll timeout instantly in case there are > signals pending and restart the given syscall after handlers run?
If there are signals pending in the host kernel poll will *already* return immediately. If there is a signal pending in the QEMU signal queue (because the host kernel just delivered it to us) then there will always be a window between the point where you say "ok, queue is empty" and actually doing the host syscall, where a signal could be delivered and put in the queue. You cannot fix this bug in the way you are trying to: you must handle this case by longjumping out of the signal handler. I've already sketched the correct design for fixing this. [to anybody in the peanut gallery who is thinking about pselect() now: yes, you could perhaps hack something up with that, but it would still be a big patch with a bunch of corner cases to review, and it would only fix this bug for this particular syscall, not in general.] -- PMM
