qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support


From: Mike Frysinger
Subject: Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support
Date: Sun, 23 Jan 2011 17:54:04 -0500

On Sun, Jan 23, 2011 at 17:35, Peter Maydell wrote:
> On 23 January 2011 21:35, Mike Frysinger wrote:
>> On Sun, Jan 23, 2011 at 16:25, Peter Maydell wrote:
>>> This looks wrong -- ppoll() is supposed to be atomic, but
>>> your implementation isn't. Why can't we just implement this
>>> by calling the host ppoll? (might need a configure test, but
>>> that's straightforward.)
>>
>> it's atomic from the apps' point of view, so what does it matter ?
>
> It's not atomic because signals can arrive in the gaps
> between your calls to sigaction and poll (even if qemu doesn't
> deliver them to the guest until we're done). ppoll() is supposed
> to return EINTR if interrupted by a signal, but if a signal arrives
> before you call poll() then you won't notice it so you won't
> return, and the app might hang.

i know how host signals work, but my limited understanding of how qemu
works is that its guest signal handling would make this a non-issue.
if that isnt the case, then i can trivially convert it to ppoll.

> Looks like this same issue came up with a proposed pselect
> patch last year:
> http://www.mail-archive.com/address@hidden/msg28339.html
> (together with some remarks about it being better not to
> trust buggy libcs and go straight for the host syscall.)

i also need pselect, and i have a local patch to support it (the same
way i've implemented ppoll).  returning ENOSYS is unacceptable as it
assumes the port in question can fall back to another select variant.
but if the arch *only* supports pselect6, then there is nothing to
fall back to if select/newselect are not supported by the arch.
-mike



reply via email to

[Prev in Thread] Current Thread [Next in Thread]