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
On 01.12.2012, at 12:27, Peter Maydell wrote:
On 1 December 2012 10:29, Janne Karhunen 955...@bugs.launchpad.net wrote:
this blocks forever, because the thing that would wake it up is the
signal handler writing to the pipe we're selecting on, but we will never
run the signal handler until
On 3 December 2012 21:20, Alexander Graf ag...@suse.de wrote:
Could you please try and see if this patch makes a difference?
http://repo.or.cz/w/qemu/agraf.git/patch/489924aa0115dc6cfcd4e91b0747da4ff8425d1f
I think the answer will turn out to be no (though it's worth
testing anyway), because
On 1 December 2012 10:29, Janne Karhunen 955...@bugs.launchpad.net wrote:
this blocks forever, because the thing that would wake it up is the
signal handler writing to the pipe we're selecting on, but we will never
run the signal handler until select exits
Duh, makes sense, have to think
On 28 November 2012 08:42, Janne Karhunen 955...@bugs.launchpad.net wrote:
Peter, I have qemu chrootable test case under which you could fire one
command to hit the bug reliably. Only issue is, are you willing to take
a peek at 100M extractable tarball? If not, I'll try to create a smaller
On 25 November 2012 20:40, Tim Penhey tim.pen...@canonical.com wrote:
Peter, if you try to run the cmake file for lp:unity you should hit it.
I'm afraid that's way too little detail. Assume I know nothing about
launchpad, cmake or unity, and give me a set of instructions I
can run on a machine
