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 imme
On 3 December 2012 21:20, Alexander Graf 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 the syscal
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
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 thi
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 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 which isn't necessarily r
