From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108455 invoked by alias); 1 Jun 2015 18:41:59 -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 108434 invoked by uid 89); 1 Jun 2015 18:41:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Message-ID: <556CA772.2060207@redhat.com> Date: Mon, 01 Jun 2015 19:47: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: Szabolcs Nagy , GNU C Library Subject: Re: [PATCH] pthread_once hangs when init routine throws an exception [BZ #18435] References: <556B7F10.40209@redhat.com> <556C31DE.4020803@arm.com> In-Reply-To: <556C31DE.4020803@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-06/txt/msg00022.txt.bz2 > i think this should be fixed in libstdc++ even if glibc guarantees > that exceptions work from the pthread_once init function. I'm not sure this is fixable in libstdc++ without giving up interoperability with the rest of glibc (handling forks) or without relying on glibc's implementation details, and without breaking compatibility. But this patch is a useful improvement to glibc irrespective of libstdc++ since its pthread_once is already exception safe on x86. Making it exception-safe on other targets allows more mixed-language code to be portable. Beyond portability, avoiding a deadlock also renders moot any security concerns about using the API as a vector for denial of service attacks. > > posix cannot give c++ exception safety guarantees. > (even if the rationale has vague statements along those lines). You're right that POSIX cannot really speak about exception safety. But POSIX shouldn't (and doesn't) prevent programs written in languages with exceptions from making use of its APIs. pthread_once also isn't the only POSIX API that interacts with exceptions. Atexit, bsearch, lsearch and qsort are examples of others. In glibc, as far as I can tell, they all work correctly in the presence of exceptions. Looking ahead, as glibc implements C11 threads and as C++ adopts C11, making C11 call_once deal with exceptions the same way C++ 11 std::call_once does will likely become a (C++) requirement. > so maybe libstdc++ should consider implementing locks and call_once > with the correct semantics independent of libc (and then maybe it > can get rid of the horrible gthr-posix.h weak reference hacks too). I suspect implementing std::call_once independently of glibc isn't possible without breaking compatibility (but I'd have to study the spec and libstdc++ code to say for certain). Beyond call_once, C++ 11 encourages implementations to provide a member function called native_handle() that returns a reference to the underlying native object. libstdc++ mutex (and other classes) expose this member function to provide interoperability with pthreads. As a result, reimplementing libstdc++ independently of libc is impossible without losing such interoperability and without breaking compatibility with existing code. Martin