On 1 December 2012 10:29, Janne Karhunen <email address hidden> 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 about this. Thank you for great analysis
> :)
>
> Apparently have to dig into qemu's code to understand this better, but
> first thought was that do you think it would be possible to add some
> crude hack bit in qemu's signal handler which we could 'almost
> atomically' check prior to entering system poll/select/read/whatnot ?
> This bit would tell there are user signals queued and handlers should be
> executed first.. ?
Nope, it's still not going to be non-racy that way (and it would still
be a pretty invasive change so it doesn't really make it easier either
I think).
On 1 December 2012 10:29, Janne Karhunen <email address hidden> wrote: read/whatnot ?
>> 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 about this. Thank you for great analysis
> :)
>
> Apparently have to dig into qemu's code to understand this better, but
> first thought was that do you think it would be possible to add some
> crude hack bit in qemu's signal handler which we could 'almost
> atomically' check prior to entering system poll/select/
> This bit would tell there are user signals queued and handlers should be
> executed first.. ?
Nope, it's still not going to be non-racy that way (and it would still
be a pretty invasive change so it doesn't really make it easier either
I think).
-- PMM