On 11/11/13 19:03, Max Filippov wrote:
> On Mon, Nov 11, 2013 at 8:50 PM, Eric Blake wrote:
>> Quick - identify the bug in this code (from ui/curses.c):
>>
>> static void curses_winch_handler(int signum)
>> {
>> struct winsize {
>> unsigned short ws_row;
>> unsigned short ws_co
On 11/11/13 18:47, Paolo Bonzini wrote:
> Il 11/11/2013 18:13, Peter Maydell ha scritto:
That said, aren't all signals in QEMU (except SIG_IPI) caught with
signalfd and the handlers run synchronously in the iothread?
>> Eric specifically points out one which is not.
>> (I'm pretty sure th
On Mo, 2013-11-11 at 18:47 +0100, Paolo Bonzini wrote:
> Il 11/11/2013 18:13, Peter Maydell ha scritto:
> >> > That said, aren't all signals in QEMU (except SIG_IPI) caught with
> >> > signalfd and the handlers run synchronously in the iothread?
> > Eric specifically points out one which is not.
>
On Mon, Nov 11, 2013 at 8:50 PM, Eric Blake wrote:
> Quick - identify the bug in this code (from ui/curses.c):
>
> static void curses_winch_handler(int signum)
> {
> struct winsize {
> unsigned short ws_row;
> unsigned short ws_col;
> unsigned short ws_xpixel; /* unus
On 11/11/2013 10:05 AM, Paolo Bonzini wrote:
>
> That said, aren't all signals in QEMU (except SIG_IPI) caught with
> signalfd and the handlers run synchronously in the iothread?
signalfd is currently a Linux-only concept - what happens on BSD?
--
Eric Blake eblake redhat com+1-919-301-3
Il 11/11/2013 18:13, Peter Maydell ha scritto:
>> > That said, aren't all signals in QEMU (except SIG_IPI) caught with
>> > signalfd and the handlers run synchronously in the iothread?
> Eric specifically points out one which is not.
> (I'm pretty sure that 'reinstall signal handler at
> end of sig
On 11/11/2013 10:13 AM, Peter Maydell wrote:
> On 11 November 2013 17:05, Paolo Bonzini wrote:
>> That said, aren't all signals in QEMU (except SIG_IPI) caught with
>> signalfd and the handlers run synchronously in the iothread?
>
> Eric specifically points out one which is not.
> (I'm pretty sur
On 11 November 2013 16:56, Anthony Liguori wrote:
> On Mon, Nov 11, 2013 at 8:50 AM, Eric Blake wrote:
>> Here's a hint: ioctl() can clobber errno. But if a signal handler is
>> called in the middle of other code that is using errno, then the handler
>> MUST restore the value of errno before ret
On 11 November 2013 17:05, Paolo Bonzini wrote:
> That said, aren't all signals in QEMU (except SIG_IPI) caught with
> signalfd and the handlers run synchronously in the iothread?
Eric specifically points out one which is not.
(I'm pretty sure that 'reinstall signal handler at
end of signal handl
On 11/11/2013 09:56 AM, Anthony Liguori wrote:
>> Here's a hint: ioctl() can clobber errno. But if a signal handler is
>> called in the middle of other code that is using errno, then the handler
>> MUST restore the value of errno before returning, if it is to guarantee
>> that the interrupted con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 11/11/2013 18:08, Eric Blake ha scritto:
>>> That said, aren't all signals in QEMU (except SIG_IPI) caught
>>> with signalfd and the handlers run synchronously in the
>>> iothread?
> signalfd is currently a Linux-only concept - what happens on BSD?
Il 11/11/2013 17:56, Anthony Liguori ha scritto:
> On Mon, Nov 11, 2013 at 8:50 AM, Eric Blake wrote:
>> Quick - identify the bug in this code (from ui/curses.c):
>>
>> static void curses_winch_handler(int signum)
>> {
>> struct winsize {
>> unsigned short ws_row;
>> unsigned s
On Mon, Nov 11, 2013 at 8:50 AM, Eric Blake wrote:
> Quick - identify the bug in this code (from ui/curses.c):
>
> static void curses_winch_handler(int signum)
> {
> struct winsize {
> unsigned short ws_row;
> unsigned short ws_col;
> unsigned short ws_xpixel; /* unus
Quick - identify the bug in this code (from ui/curses.c):
static void curses_winch_handler(int signum)
{
struct winsize {
unsigned short ws_row;
unsigned short ws_col;
unsigned short ws_xpixel; /* unused */
unsigned short ws_ypixel; /* unused */
} ws;
14 matches
Mail list logo