WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signal

To: qemu-devel@xxxxxxxxxx
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals.
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Sat, 06 Sep 2008 21:41:43 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Jamie Lokier <jamie@xxxxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxxxxx>
Delivery-date: Sat, 06 Sep 2008 19:42:54 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <18614.28941.823723.388725@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <18612.1900.73781.314743@xxxxxxxxxxxxxxxxxxxxxxxx> <48B41B7E.40708@xxxxxxxxxxxxx> <18612.7267.832361.270651@xxxxxxxxxxxxxxxxxxxxxxxx> <48B41F55.1000909@xxxxxxxxxxxxx> <18612.8502.305043.233934@xxxxxxxxxxxxxxxxxxxxxxxx> <48B422F2.1090900@xxxxxxxxxxxxx> <20080826174729.GB25893@xxxxxxxxxxxxx> <18613.8801.187470.178088@xxxxxxxxxxxxxxxxxxxxxxxx> <20080827162719.GC25387@xxxxxxxxxxxxx> <18613.33339.351040.938403@xxxxxxxxxxxxxxxxxxxxxxxx> <20080827184146.GD27491@xxxxxxxxxxxxx> <18614.28941.823723.388725@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080723)
Ian Jackson wrote:
Jamie Lokier writes ("Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle 
terminating signals."):
A quick read of Glibc 2.3.1 source says its AIO code does not change
the signal mask when it creates an AIO handling thread.

Thanks for investigating that.

(This might be a Glibc bug - threads you don't know about shouldn't be
receiving your signals, should they?)

Yes, it's a bug.  (I wonder why my test program didn't expose it.)

That means if it wasn't masked when you issued the first AIO request,
it won't be masked in that thread.

In practice since we use aio this probably means we can't rely on
signal blocking except for signals which qemu keeps blocked `nearly
all' the time.  So pipe-to-self in the signal handler is the way to
go.

In my signalfd patch, we block SIGUSR2 all the time so it shouldn't be affected by this "bug". We use sigwait or signalfd to receive the signal.

Regards,

Anthony Liguori


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Xen-devel] Re: [Qemu-devel] [PATCH 01/13] Handle terminating signals., Anthony Liguori <=