From users-return-1010-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org Wed Mar 04 00:36:47 2009 Return-Path: Delivered-To: apmail-qpid-users-archive@www.apache.org Received: (qmail 78996 invoked from network); 4 Mar 2009 00:36:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2009 00:36:47 -0000 Received: (qmail 92818 invoked by uid 500); 4 Mar 2009 00:36:46 -0000 Delivered-To: apmail-qpid-users-archive@qpid.apache.org Received: (qmail 92802 invoked by uid 500); 4 Mar 2009 00:36:46 -0000 Mailing-List: contact users-help@qpid.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@qpid.apache.org Delivered-To: mailing list users@qpid.apache.org Received: (qmail 92788 invoked by uid 99); 4 Mar 2009 00:36:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Mar 2009 16:36:46 -0800 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gsim@redhat.com designates 66.187.233.31 as permitted sender) Received: from [66.187.233.31] (HELO mx1.redhat.com) (66.187.233.31) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 00:36:38 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n240aHOO007015 for ; Tue, 3 Mar 2009 19:36:17 -0500 Received: from pobox.fab.redhat.com (pobox.fab.redhat.com [10.33.63.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n240aJvT018830 for ; Tue, 3 Mar 2009 19:36:20 -0500 Received: from [10.11.12.8] (vpn-12-8.rdu.redhat.com [10.11.12.8]) by pobox.fab.redhat.com (8.13.1/8.13.1) with ESMTP id n240aFfg014271 for ; Tue, 3 Mar 2009 19:36:16 -0500 Message-ID: <49ADCDA0.2020801@redhat.com> Date: Wed, 04 Mar 2009 00:38:56 +0000 From: Gordon Sim Organization: Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.,Registered in England and Wales under Company Registration No. 3798903,Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland) User-Agent: Thunderbird 1.5.0.2 (X11/20060501) MIME-Version: 1.0 To: users@qpid.apache.org Subject: Re: Potential deadlock with LocalQueue::get() / Session::close()? References: <1236119258.30097.59.camel@beef.Belkin> In-Reply-To: <1236119258.30097.59.camel@beef.Belkin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Virus-Checked: Checked by ClamAV on apache.org Rob Springer wrote: > Hey all - I've noticed a problem when debugging some code, and it looks > to my eyes like there's a potential deadlock situation using the timed > LocalQueue::get() command when a fatal interrupt occurs. I've posted > what I hope is clear reproducer code below. Could someone else take a > quick look at it and tell me if I'm crazy or correct? The api is in general not safe to call from a signal handler. While the mutexes are re-entrant, deadlocks around condition variables is very likely. If you need to use interrupts, maybe the best solution is to have a 'signal queue' onto which notifications of signals are place, with a dedicated thread then processing that queue and invoking on the api to cleanup. Of course that thread and the signal queue implementation will need to allow for the case where it is interrupted to actually handle the signal, but as that would be a more focused scope it would be easier than making the entire api interrupt safe. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscribe@qpid.apache.org