From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34037 invoked by alias); 28 Jun 2019 16:08:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 34023 invoked by uid 89); 28 Jun 2019 16:08:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=fwd, H*f:sk:2175092 X-HELO: mail.codeweavers.com Received: from mail.codeweavers.com (HELO mail.codeweavers.com) (50.203.203.244) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Jun 2019 16:08:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codeweavers.com; s=6377696661; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pvYJfRdmEUmhkScdOt8uHX+7a66j4E/rz2S4tAb+ZWk=; b=mCY3Zy4PF2FER/0l+biXWuZx4n GLA5rNmd1DxKSCSPwEDNVQeEp/3ZCSCWBeeSY2TY853v1yXTfsM+DJV6coxK1kYC/5kEdxaOpf9ru 50H45hCMei25+AmKkchkJu1jXdy82IdXbmrXhshyM4UJb7gPfGz4TGzs6DY7AOvEd8Us=; Received: from nowy.psi.wroc.pl ([193.239.56.40] helo=[10.0.0.2]) by mail.codeweavers.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1hgtQd-00073Y-Vu; Fri, 28 Jun 2019 11:08:49 -0500 Subject: Re: [Mingw-w64-public] Fwd: [patch] Reimplement GNU threads library on native Windows To: mingw-w64-public@lists.sourceforge.net, NightStrike Cc: Eric Botcazou , GCC Patches , libstdc++@gcc.gnu.org References: <2175092.5hV0XgF4mA@polaris> From: Jacek Caban Message-ID: <30ed46f2-6672-f805-9627-05c31c8a708e@codeweavers.com> Date: Fri, 28 Jun 2019 16:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -106.0 X-SW-Source: 2019-06/txt/msg01857.txt.bz2 Hi Eric, On 6/28/19 3:42 PM, NightStrike wrote: > FYI, Eric posted this today to the GCC patches list. This may be of > great interest to many who would prefer native threads instead of the > winpthreads posix style interface. > > Great work, Eric! I look forward to trying this out! > > ---------- Forwarded message --------- > From: Eric Botcazou > Date: Fri, Jun 28, 2019 at 6:51 AM > Subject: [patch] Reimplement GNU threads library on native Windows > To: > Cc: > > > Hi, > > this reimplements the GNU threads library on native Windows (except for the > Objective-C specific subset) using direct Win32 API calls, in lieu of the > implementation based on semaphores. This base implementations requires > Windows XP/Server 2003, which is the default minimal setting of MinGW-W64. > This also adds the support required for the C++11 threads, using again direct > Win32 API calls; this additional layer requires Windows Vista/Server 2008 and > is enabled only if _GTHREADS_USE_COND is defined to 1. > > This also changes libstdc++ to setting _GTHREADS_USE_COND to 1 when the switch > --enable-libstdcxx-threads is passed, which means that C++11 threads are still > disabled by default on native Windows and that you need to explicitly pass the > switch to enable them. The 30_threads chapter of the testsuite is clean. > > Tested on i686-pc-mingw32 and x86_64-pc-mingw32, OK for the mainline? It's indeed great to see this. Thank you! > +/* The implementation strategy for the c++0x thread support is as follows. > + > + A GNU thread is represented by a Win32 HANDLE that is obtained when the > + Win32 thread is created, except of course for the initial thread. This > + Win32 HANDLE is stored in a descriptor keyed from TLS memory for every > + thread, so the self routine can return it instead of having to duplicate > + the pseudo-handle returned by GetCurrentThread each time it is invoked. > + For the initial thread, this Win32 HANDLE is created during the first > + call to the self routine using the aforementioned technique. > + > + Note that the equal routine compares the identifier of threads instead > + of their Win32 HANDLE, which will give the correct positive answer even > + in the case where distinct Win32 HANDLEs have been created for the same > + thread by multiple instances of libgcc included in the link. */ Note that this will cause handle leaks if used across multiple libgcc instances, through. > +#include "gthr-win32.h" > + > +/* The thread descriptor keyed from TLS memory. */ > +struct __gthr_win32_thr_desc > +{ > + void *(*func) (void*); > + void *args; > + HANDLE h; > +}; > + > +/* The TLS key used by one instance of the library. */ > +static __gthread_key_t __gthr_win32_tls = TLS_OUT_OF_INDEXES; > + > +/* The initialization device for the TLS key. */ > +static __gthread_once_t __gthr_win32_tls_once = __GTHREAD_ONCE_INIT; > + > +/* Initialize the TLS key. */ > + > +static void > +__gthr_win32_tls_init (void) > +{ > + if (__gthread_key_create (&__gthr_win32_tls, free)) > + abort (); > +} You don't really need to store the whole __gthr_win32_thr_desc in TLS. If you stored just the handle, this wouldn't need a destructor. Thanks, Jacek