From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 161691F85A for ; Tue, 10 Jul 2018 12:35:47 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=nzan6LUgD5Tms0fI GNPRdLTxJeAtmdlS1kLYwa+CpNjIxReSVJrI/NABimBLO1X6uiWhAg1cllRdVw2k XPbuHEMpUUxIlYuvlnOo9BkRoZNueg5fufg+/srMf5JTFnoeFP8B3ZR02WntuexA yD3SENrvDLeqL3WHNb9SA/t+oDQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=Fjr2d7NS/V2XIMkOHEJ4Zn ekUpo=; b=Hub0b5vChBtRev/G5CozUPqdTAhEHcqRgTtPAfmhFXwsDKkNgtzuUP iRTv1sjulR4L5hS35+hV/A0Sb5CBWysBnoIlSJJBfu9G6nBc1hBzNnyAzCkOE3jw AegKGDCXnpxtQ+vAouxZSg22R9P4K2lfgMVAnIrj7fQ14Tvt0V6eE= Received: (qmail 30162 invoked by alias); 10 Jul 2018 12:35:44 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 30153 invoked by uid 89); 10 Jul 2018 12:35:43 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-ua0-f196.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eY4BUdLAPA9chTwfsmv7W+btXNoNpZlLWySUztUZI34=; b=OvCo+pk0qCCUMQcA568m9bD0HhuSWwZerUC4A3KHuE4onyEI/XWw10wazhbUr1jUNE JfuZ78FC07qGTCkG+eM3uRtETv6fyphGa3JhUHqtWvk4ocxeRfnjLH/4UIULnmzxuhTM 2kzshjvelXc2fBeehsf1p5a+inJ9WAaIM15Ls= Subject: Re: [PATCH v8 2/8] nptl: Add C11 threads mtx_* functions To: Florian Weimer , libc-alpha@sourceware.org References: <1517591084-11347-1-git-send-email-adhemerval.zanella@linaro.org> <1517591084-11347-3-git-send-email-adhemerval.zanella@linaro.org> <44460c52-bff8-d7a7-4d7e-f017ad268c21@redhat.com> From: Adhemerval Zanella Openpgp: preference=signencrypt Message-ID: <4be08a33-8957-0494-857b-5c26869778b1@linaro.org> Date: Tue, 10 Jul 2018 09:35:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <44460c52-bff8-d7a7-4d7e-f017ad268c21@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/07/2018 09:51, Florian Weimer wrote: > On 02/02/2018 06:04 PM, Adhemerval Zanella wrote: >> This patch adds the mtx_* definitions from C11 threads (ISO/IEC 9899:2011), >> more specifically mtx_init, mtx_destroy, mtx_lock, mtx_timedlock, mtx_trylock, >> mtx_unlock, and required types. >> >> Mostly of the definitions are composed based on POSIX conterparts, and mtx_t >> is also based on internal pthread fields, but with a distinct internal layout >> to avoid possible issues with code interchange (such as trying to pass POSIX >> structure on C11 functions and to avoid inclusion of pthread.h).  The idea >> is to make possible to share POSIX internal implementations for mostly of >> the code (and making adjustment only when required). > > Should we check for the supported mutex types and error out if the type does not match?  The interface does not support the full range of error codes required by robust mutexes, for example—EOWNERDEAD is missing. > I am not sure if adding extra tests will yield any gain, specially on mutex operations which users would expect optimized fast paths. I really think we should handle as undefined behaviour if uses try to use pthread_t objects with c11 threads function (in similar manner it is undefined behaviour if uses messes with internal pthread_mutex_t objects data directly).