From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75940 invoked by alias); 22 Jun 2015 19:55:32 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 75921 invoked by uid 89); 22 Jun 2015 19:55:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <55886830.80000@redhat.com> Date: Tue, 23 Jun 2015 07:48:00 -0000 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: GNU C Library Subject: [PING 2] Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435] References: <556B7F10.40209@redhat.com> <557741C5.5060203@redhat.com> <557F2624.6000503@redhat.com> In-Reply-To: <557F2624.6000503@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00753.txt.bz2 Are there any concerns with this patch? https://sourceware.org/ml/libc-alpha/2015-06/msg00348.html Martin On 06/15/2015 01:23 PM, Martin Sebor wrote: > On 06/09/2015 01:43 PM, Martin Sebor wrote: >> Attached is an updated version of the patch that addresses >> the LDFLAGS -> LDLIBS comment. Retested on ppc64. >> >> Is it okay to commit? > > Are there any outstanding concerns with this version of > the patch or is it good to commit? > > Martin > >> >> Martin >> >> On 05/31/2015 03:37 PM, Martin Sebor wrote: >>> The C++ 2011 std::call_once function is specified to allow >>> the initialization routine to exit by throwing an exception. >>> Such an execution, termed exceptional, requires call_once to >>> propagate the exception to its caller. A program may contain >>> any number of exceptional executions but only one returning >>> execution (which, if it exists, must be the last execution >>> with the same once flag). >>> >>> On POSIX systems such as Linux std::call_once is implemented >>> in terms of pthread_once. However, as discussed in libstdc++ >>> bug 66146 - "call_once not C++11-compliant on ppc64le," GLIBC's >>> pthread_once hangs when the initialization function exits by >>> throwing an exception on at least arm and ppc64 (though >>> apparently not on x86_64). This effectively prevents call_once >>> from conforming to the C++ requirements since there doesn't >>> appear to be a thread-safe way to work around this problem in >>> libstdc++. >>> >>> The attached patch changes pthread_once to handle gracefully >>> init functions that exit by throwing exceptions. It has been >>> tested on ppc64, ppc64le, and x86_64 with no regressions. >>> >>> During the discussion of the bug concerns were raised about >>> whether the use case of throwing exceptions from the >>> pthread_once init routine is intended to be supported either >>> by POSIX, or by GLIBC. After some research I believe that both >>> POSIX and GLIBC have, in fact, intended to support it, for at >>> least two reasons: >>> >>> First, the POSIX Rationale states in section Thread Cancellation >>> Overview, under Thread Cancellation Cleanup Handlers, that: >>> >>> it is an explicit goal of POSIX.1-2008 to be compatible with >>> existing exception facilities and languages having exceptions. >>> >>> Second, as is evident from the comment above the pthread_once >>> declaration in GLIBC (quoted below), GLIBC too has intended >>> to support this use case since 2004 when the comment was >>> added (and the __THROW specification removed from the API): >>> >>> ... >>> The initialization functions might throw exception which >>> is why this function is not marked with __THROW. */ >>> >>> Martin >> >