[{"id":1804829,"web_url":"http://patchwork.ozlabs.org/comment/1804829/","msgid":"<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>","list_archive_url":null,"date":"2017-11-15T08:09:03","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":14312,"url":"http://patchwork.ozlabs.org/api/people/14312/","name":"Florian Weimer","email":"fweimer@redhat.com"},"content":"On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:\n> This patch adds the thrd_* definitions from C11 threads (ISO/IEC 9899:2011),\n> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,\n> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.\n> \n> Mostly of the definitions are composed based on POSIX conterparts, such as\n> thrd_t (using pthread_t).\n\nI have skimmed the C11 discussion of these types, and C11 says that \nmtx_t et al. are “identifiers”. To me, this suggests they are handles, \njust like pthread_t in the POSIX threads implementation.\n\nI'm sorry, but this would make the current implementation based on \npthread types (without indirection) invalid. 8-(\n\nThanks,\nFlorian","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87121-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"mj6sd+Ps\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycH8Y6PP1z9sBW\n\tfor ;\n\tWed, 15 Nov 2017 19:09:17 +1100 (AEDT)","(qmail 86650 invoked by alias); 15 Nov 2017 08:09:11 -0000","(qmail 86632 invoked by uid 89); 15 Nov 2017 08:09:10 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:cc:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=M1u/KTO/ZHpxZqk7\n\t3FF4q7W9mDcYYFRH+Z38SoFqPk9YO53WO7F+HdqFA9NLAfsIs8lEBYiW/X6KPUG0\n\tYMyPH+GigJTsybdAZ3fJggUb1QjRYqkJEfGZWV4qvQQIry0y7KooYxqI8kuygtwC\n\tmw/vFnJC4AicDYuqQeXu9C898SU=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:references:cc:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=iPXYQ7mBhQnEAIsIOkFfdr\n\t5+vNA=; b=mj6sd+Pst741QZyc870l7p4G0UDqhG22M2Bz//noyFYG+rJdDxl6DS\n\tmK1lLKRHWTcP+raK16IgLVxOP3f5kcw6fVyb9ZkJxhpxI065S87rvo0BNmm/Qvza\n\to8e2hcmmSx0wQmoxw+SYjSTADM6VtH4exDdywLnuRcouhNvjzbfPE=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.7 required=5.0 tests=BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RP_MATCHES_RCVD,\n\tSPF_HELO_PASS autolearn=no version=3.3.2\n\tspammy=Hx-languages-length:765,\n\tHContent-Transfer-Encoding:8bit","X-HELO":"mx1.redhat.com","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Adhemerval Zanella ","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>","Cc":"libc-alpha@sourceware.org","From":"Florian Weimer ","Message-ID":"<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>","Date":"Wed, 15 Nov 2017 09:09:03 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit"}},{"id":1804969,"web_url":"http://patchwork.ozlabs.org/comment/1804969/","msgid":"<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>","list_archive_url":null,"date":"2017-11-15T11:22:42","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 15/11/2017 06:09, Florian Weimer wrote:\n> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:\n>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC\n>> 9899:2011),\n>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,\n>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.\n>>\n>> Mostly of the definitions are composed based on POSIX conterparts,\n>> such as\n>> thrd_t (using pthread_t).\n>\n> I have skimmed the C11 discussion of these types, and C11 says that\n> mtx_t et al. are “identifiers”.  To me, this suggests they are\n> handles, just like pthread_t in the POSIX threads implementation.\nMy understanding is \"identifiers\" follow the definition from C11 6.2.1\nwhich does\nnot exclude a tag/struct to represent it. A possible issue is POSIX has\na model\no flat address space that is shared between all thread while C standard\nmakes it\nimplementation defined (allowing for instance segmented address space or\ndifferent vmas for hybrid computing). However I think C11 standard makes\nno amend to address it and although there is some suggestions [1] to add\nfeature tests to handle it, it was no incorporated.\n\n[1]\nhttps://gustedt.wordpress.com/2012/10/14/c11-defects-c-threads-are-not-realizable-with-posix-threads/\n\n>\n> I'm sorry, but this would make the current implementation based on\n> pthread types (without indirection) invalid. 8-(\nThat is not my understanding. Could you point in C11 standard where\nidentifier\nin thread.h definition exclude the use of tag types?\n\n>\n> Thanks,\n> Florian","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87131-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"fTBkpqEN\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycMS13yMkz9sBW\n\tfor ;\n\tWed, 15 Nov 2017 22:22:57 +1100 (AEDT)","(qmail 117956 invoked by alias); 15 Nov 2017 11:22:51 -0000","(qmail 117944 invoked by uid 89); 15 Nov 2017 11:22:51 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=kqIhkazveV1rTgIa\n\t9XOAAvZThBL9p5fphlXEw51DCBzXgrTOKWs4fGK+SnTpS5Z5hkN3OYLI+QW+9ZwH\n\tMZlAWAWXdvWmAX93M5o8GBfa3I989sXV/iwMFlsARM4VAYRo/cKq5b+ReS/vANzp\n\tx8QHvQMXD9Y2i0quW0vjfAOgSq4=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=KIQ7s4YqZv2SxumJrVSpTQ\n\ttTfkw=; b=fTBkpqENUeiBtN7i5A4rRxiDPi3ldVs/Yan57dZDijI2GzkZiZDfTC\n\t8+d2DLNBrlsW2GFG6tn1OKAxDawEICHuaCsONntt6N66I7Meuqup8JXxHoYLNc1e\n\tP5BlPOsaxykzMrpiBF/TbuxPWvIAzJebAeInPSoWj0qYZgg5uObgE=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-3.2 required=5.0 tests=AWL, BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=understanding","X-HELO":"mail-qt0-f193.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding\n\t:content-language;\n\tbh=qbvyJH5XlQ6deGQa9EImqs5qWWCw158mlSvGcg1HbzQ=;\n\tb=HdJ9Hmvs1dwRttS3a650MEn5olbj2ZAjklpB3kxywBJApWJG2hfWE3nDrdVrB4bFS3\n\tvshjJA8UYI+qdssviOPPocfb4K6/vbaTML8bs5/zg0uQncAUaYv7jJGfTa5eVf0Y+52q\n\tpnBbgXQ0FFh+nRSf1xdrd0f2ALDhWTltBdyWw9vwO6VTNcSUEQFZCN26FspCd2wUDNmK\n\tv1PFVIM1sd3dJJgcKZ92IyzCdx6EPvl9BLiMUqrTi1U9pHCKxcgHo2nJG0y89jbWEKnF\n\tOFRL4tjmeUK4LhXsLZVuLuxy5YTBwRUD8tI9ANXSWcR3v3sHGre3HHSEcoQOcxz34hm+\n\tYtKA==","X-Gm-Message-State":"AJaThX4Ln2viudU4OdZ6ah+s2YxYujT/yhCJNr0bHobkud3UTaJp041u\n\tjD7+KYKZ6FvjHKPeLrfd13UsYRIXAXI=","X-Google-Smtp-Source":"AGs4zMY+8z5mHUCyhcWs8KlN8lJmJxoLdlMswThD0ca5t7kZMOEAFxSEHeONl0NlU8drtBFqin8wgA==","X-Received":"by 10.200.34.245 with SMTP id g50mr24159329qta.62.1510744967479; \n\tWed, 15 Nov 2017 03:22:47 -0800 (PST)","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Florian Weimer ","Cc":"libc-alpha@sourceware.org","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>\n\t<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>","From":"Adhemerval Zanella ","Message-ID":"<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>","Date":"Wed, 15 Nov 2017 09:22:42 -0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable"}},{"id":1804986,"web_url":"http://patchwork.ozlabs.org/comment/1804986/","msgid":"","list_archive_url":null,"date":"2017-11-15T12:03:19","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":14312,"url":"http://patchwork.ozlabs.org/api/people/14312/","name":"Florian Weimer","email":"fweimer@redhat.com"},"content":"On 11/15/2017 12:22 PM, Adhemerval Zanella wrote:\n> \n> \n> On 15/11/2017 06:09, Florian Weimer wrote:\n>> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:\n>>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC\n>>> 9899:2011),\n>>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,\n>>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.\n>>>\n>>> Mostly of the definitions are composed based on POSIX conterparts,\n>>> such as\n>>> thrd_t (using pthread_t).\n>>\n>> I have skimmed the C11 discussion of these types, and C11 says that\n>> mtx_t et al. are “identifiers”.  To me, this suggests they are\n>> handles, just like pthread_t in the POSIX threads implementation.\n\n> My understanding is \"identifiers\" follow the definition from C11 6.2.1\n> which does not exclude a tag/struct to represent it.\n\nI don't think “identifier” is used in this sense here.\n\nThe standard says (7.2.6.1/4):\n\n“\nThe types are\n\\begin{quote}\n \\verb|cnd_t|\n\\end{quote}\nwhich is a complete object type that holds an identifier for a condition \nvariable;\n”\n\nThe “holds an identifier” suggests to me that this use of the term \n“identifier” does not refer to the C language construct. The \ndefinitions in ISO/IEC 2382:2015(en) do not seem to be applicable, either.\n\nThe POSIX model assumes that the identity of a condition variable is \ndetermined by its address. This means that pthread_cond_t cannot hold \nan identifier, it is the thing itself, which means, among other things, \nthat you cannot make a copy (e.g. using memcpy) and the copy will behave \nin the same way as the original, accessing the same condition variable.\n\nIf something is just an identifier for something else, it strongly \nsuggests to me that the underlying object is separate, and I can use a \nbit-wise identical identifier to reference the identical underlying object.\n\nThanks,\nFlorian","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87132-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"yMFmt/7Y\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycNLw29C0z9s72\n\tfor ;\n\tWed, 15 Nov 2017 23:03:35 +1100 (AEDT)","(qmail 130902 invoked by alias); 15 Nov 2017 12:03:28 -0000","(qmail 130891 invoked by uid 89); 15 Nov 2017 12:03:28 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=SjLIm215y3JIcGpd\n\ta9kDUJhWaKOV4nyXshOLLzbNLwugDb7clDgqxtqjFNj1w4kVZ5RJd+Bj6ft1c1e1\n\t28SPpR5ijgUxPM2GxYKFgckQH2RXn1Ik+A5a99UihW+wdB7ot23PAEWFcOprxfd5\n\tnIsCscBXSi6psubuMv+zVIxO7tY=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=yEoKc3L2ZJNmVtPGeK+kka\n\tqGTGQ=; b=yMFmt/7YmICVcPHpNxUVVRjWglYo5ecXZDLvCaobMjFqFQ2QzBKJTa\n\tMLAZPZekCK5rq+WIm01xyh4aE+aZhfrgPFkFMY+i4nerKWwJM4KZps6/qqdCcH3O\n\t2Rn13STqVkp3xcTzK/h6AGmR+ijvh+EnojDHG8+JfO3gG7+vS9kcc=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.7 required=5.0 tests=BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RP_MATCHES_RCVD,\n\tSPF_HELO_PASS autolearn=no version=3.3.2\n\tspammy=Hx-languages-length:1932, understanding, among,\n\tHContent-Transfer-Encoding:8bit","X-HELO":"mx1.redhat.com","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Adhemerval Zanella ","Cc":"libc-alpha@sourceware.org","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>\n\t<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>\n\t<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>","From":"Florian Weimer ","Message-ID":"","Date":"Wed, 15 Nov 2017 13:03:19 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit"}},{"id":1804994,"web_url":"http://patchwork.ozlabs.org/comment/1804994/","msgid":"","list_archive_url":null,"date":"2017-11-15T12:43:28","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 15/11/2017 10:03, Florian Weimer wrote:\n> On 11/15/2017 12:22 PM, Adhemerval Zanella wrote:\n>>\n>>\n>> On 15/11/2017 06:09, Florian Weimer wrote:\n>>> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:\n>>>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC\n>>>> 9899:2011),\n>>>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,\n>>>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.\n>>>>\n>>>> Mostly of the definitions are composed based on POSIX conterparts,\n>>>> such as\n>>>> thrd_t (using pthread_t).\n>>>\n>>> I have skimmed the C11 discussion of these types, and C11 says that\n>>> mtx_t et al. are “identifiers”.  To me, this suggests they are\n>>> handles, just like pthread_t in the POSIX threads implementation.\n>\n>> My understanding is \"identifiers\" follow the definition from C11 6.2.1\n>> which does not exclude a tag/struct to represent it.\n>\n> I don't think “identifier” is used in this sense here.\n>\n> The standard says (7.2.6.1/4):\n>\n> “\n> The types are\n> \\begin{quote}\n>   \\verb|cnd_t|\n> \\end{quote}\n> which is a complete object type that holds an identifier for a\n> condition variable;\n> ”\n>\n> The “holds an identifier” suggests to me that this use of the term\n> “identifier” does not refer to the C language construct.  The\n> definitions in ISO/IEC 2382:2015(en) do not seem to be applicable,\n> either.\nI find it quite inconsistent and improbable that the threads definition\nin C11\nstandard is using a defined vocabulary in a different meaning than the rest\nof document. \n\n>\n> The POSIX model assumes that the identity of a condition variable is\n> determined by its address.  This means that pthread_cond_t cannot hold\n> an identifier, it is the thing itself, which means, among other\n> things, that you cannot make a copy (e.g. using memcpy) and the copy\n> will behave in the same way as the original, accessing the same\n> condition variable.\n>\n> If something is just an identifier for something else, it strongly\n> suggests to me that the underlying object is separate, and I can use a\n> bit-wise identical identifier to reference the identical underlying\n> object.\n\nMy understanding is C11 threads standard does not create a tightly\ndefinition\nto try accommodate possible implementations where POSIX assumptions are\nnot required or exercised. However I do not see that a more constrict\nimplementation (based on POSIX for instance) is incompatible, the link I\nprovided\nearlier is a suggestion to add features test to define which constraints are\ndefined in the environment.\n\nAlso the defined C11 threads API does not suggest me that the idea of the\ntypes are to point to a concrete identifier. For instance, to compare\nthreads\nC11 does provide thrd_equal instead of relying of memcmp for the defined\nobjects (as for bitwise underlying objects).","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87133-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"K5Hp+0EK\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycPFD0rkYz9s7v\n\tfor ;\n\tWed, 15 Nov 2017 23:43:43 +1100 (AEDT)","(qmail 5662 invoked by alias); 15 Nov 2017 12:43:37 -0000","(qmail 5651 invoked by uid 89); 15 Nov 2017 12:43:37 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=Wqi3zA98FhLwKBzD\n\tmcQ7lCCq6+qKhR3vfzLhrJlujLZ80c7YqHcN7jfrz0Gfy/0UIQ/VYrjVMQf/5KfT\n\tkd2GuLnZ5qiXr9EKat3nCG5mwoeuSNrPddppY16wrTF12P1fq7bBXNXBeCcQx/D9\n\tV/3fUwEt8lS2/S3Wv7iBL598DpY=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=PaMAz2FQRslQNlGyITLmW8\n\tU3fgc=; b=K5Hp+0EKQSqPebmUkl+XDVUU77wY+Z6xJsSID/61BX2H/SdnoEvBJc\n\tC4nPoOXDEb2RicfuJRbNnU5ElnLyiUt20Ll9SuD7J7N7OVYkKNM3aNy0b/2chnIB\n\ttAmqJ+C6fIbfS+tv4fsVbL2sHLp1gTNunoK0pALaI11FwhI+jRl6s=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-3.1 required=5.0 tests=AWL, BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=H*M:4504,\n\tvocabulary, understanding","X-HELO":"mail-qt0-f171.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-transfer-encoding\n\t:content-language;\n\tbh=vq1+7oNX9RW9PNQbQ2YqlJZnKPvZNdFRqmPmZJNQCpk=;\n\tb=E36hmSLiy8Nqdt1YfcDwR2D3P3QRrJdWdqOx8aTeXQ4hd8k+dDST0NSWu/GzYX+DPe\n\taCuqw29Cz9GbNS9pVwBREmdkaCOADGUOikBZDq8gnNebt79KhKkm2VWjNmbyAZ0Emccp\n\tk9wiGe1tz+6TMpF9EYswdchsFYHz39tUZ4OGSEovzzkN7vMad8Lwn2XOP82gCn7aoryo\n\tRRw+QLZmGHNHV19qEihFFTMAGt6Trd3TvrJHZLIxDiTcwu4jpla1/T2eA1lI8OQ1nvz6\n\th0xEYcR2ChfsJ7H0yfAymgxq05+8evKgsql3m+B+hvFqvhspJsF27eBrVPYI4nXsr1EZ\n\tALLQ==","X-Gm-Message-State":"AJaThX58Wo+8S6aah7N9U3DI25ESdhIT7H87KzjfeB0qm1zcZqHqZzxT\n\tNOlFC1g1mnFk2WBSeDWYvymS2shIbVs=","X-Google-Smtp-Source":"AGs4zMYt+Gis6wsG1+MbqHb+Fh3DmGPX3rmxoWCF1Xlcqi9XEXhjg1EAV0w1xFxJrpsnZGe1wbgatQ==","X-Received":"by 10.200.23.136 with SMTP id o8mr7135309qtj.258.1510749814105; \n\tWed, 15 Nov 2017 04:43:34 -0800 (PST)","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Florian Weimer ","Cc":"libc-alpha@sourceware.org","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>\n\t<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>\n\t<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>\n\t","From":"Adhemerval Zanella ","Message-ID":"","Date":"Wed, 15 Nov 2017 10:43:28 -0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"quoted-printable"}},{"id":1804997,"web_url":"http://patchwork.ozlabs.org/comment/1804997/","msgid":"","list_archive_url":null,"date":"2017-11-15T12:49:21","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":14312,"url":"http://patchwork.ozlabs.org/api/people/14312/","name":"Florian Weimer","email":"fweimer@redhat.com"},"content":"On 11/15/2017 01:43 PM, Adhemerval Zanella wrote:\n> \n> \n> On 15/11/2017 10:03, Florian Weimer wrote:\n>> On 11/15/2017 12:22 PM, Adhemerval Zanella wrote:\n>>>\n>>>\n>>> On 15/11/2017 06:09, Florian Weimer wrote:\n>>>> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:\n>>>>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC\n>>>>> 9899:2011),\n>>>>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,\n>>>>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.\n>>>>>\n>>>>> Mostly of the definitions are composed based on POSIX conterparts,\n>>>>> such as\n>>>>> thrd_t (using pthread_t).\n>>>>\n>>>> I have skimmed the C11 discussion of these types, and C11 says that\n>>>> mtx_t et al. are “identifiers”.  To me, this suggests they are\n>>>> handles, just like pthread_t in the POSIX threads implementation.\n>>\n>>> My understanding is \"identifiers\" follow the definition from C11 6.2.1\n>>> which does not exclude a tag/struct to represent it.\n>>\n>> I don't think “identifier” is used in this sense here.\n>>\n>> The standard says (7.2.6.1/4):\n>>\n>> “\n>> The types are\n>> \\begin{quote}\n>>   \\verb|cnd_t|\n>> \\end{quote}\n>> which is a complete object type that holds an identifier for a\n>> condition variable;\n>> ”\n>>\n>> The “holds an identifier” suggests to me that this use of the term\n>> “identifier” does not refer to the C language construct.  The\n>> definitions in ISO/IEC 2382:2015(en) do not seem to be applicable,\n>> either.\n\n> I find it quite inconsistent and improbable that the threads definition\n> in C11\n> standard is using a defined vocabulary in a different meaning than the rest\n> of document.\n\nBut how can a complete object *type* hold a C identifier? The language \ndoes not support that. We don't have call-by-name or anything like that.\n\nSo this usage doesn't make sense to me, so I assume that something else \nis meant here.\n\nI'm trying to get access to the WG papers on which the text is based. \nMaybe those illuminate what is meant here.\n\nThanks,\nFlorian","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87134-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"NMSfh6Dz\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycPMx2GfDz9s71\n\tfor ;\n\tWed, 15 Nov 2017 23:49:33 +1100 (AEDT)","(qmail 77937 invoked by alias); 15 Nov 2017 12:49:26 -0000","(qmail 77922 invoked by uid 89); 15 Nov 2017 12:49:25 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=xHw5PVntsqlFEuAW\n\t13KatHm6rpWFRFV/tKghEr/IozacdrA5brMAYh/nyBHafQoAef5BIIV134gng2q8\n\taAOIlGm1mXrNK9y4bNq9YKPRDjN+ze7tMXBAaqFSF099QYw+hhuNG3dhlcStLSvG\n\tJ4H3Ww7MaCwY6vDoFf4xeXnZQcU=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=kh+MHIst33HEA0vqUsAECP\n\tWWxaA=; b=NMSfh6Dzipi0p8Gb5agBzxQQVkvTAsfXv9e4Df616NilfeLvdHixFK\n\tmmII4phcegaexCcyhRwG9DVdUGM57qMu0IuMcLWucT086t40KWuzmdmDgcd2j+ex\n\t2CTG9xnQnDk3+VcXelWAB/OAjJBnqubwvkuN09zD06AX0g3qJ5LJE=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.7 required=5.0 tests=BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RP_MATCHES_RCVD,\n\tSPF_HELO_PASS autolearn=no version=3.3.2 spammy=vocabulary,\n\tilluminate, understanding, HContent-Transfer-Encoding:8bit","X-HELO":"mx1.redhat.com","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Adhemerval Zanella ","Cc":"libc-alpha@sourceware.org","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>\n\t<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>\n\t<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>\n\t\n\t","From":"Florian Weimer ","Message-ID":"","Date":"Wed, 15 Nov 2017 13:49:21 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit"}},{"id":1805016,"web_url":"http://patchwork.ozlabs.org/comment/1805016/","msgid":"<7b3aa01b-910f-8896-5dd3-fce1542669e9@linaro.org>","list_archive_url":null,"date":"2017-11-15T13:21:44","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 15/11/2017 10:49, Florian Weimer wrote:\n> On 11/15/2017 01:43 PM, Adhemerval Zanella wrote:\n>>\n>>\n>> On 15/11/2017 10:03, Florian Weimer wrote:\n>>> On 11/15/2017 12:22 PM, Adhemerval Zanella wrote:\n>>>>\n>>>>\n>>>> On 15/11/2017 06:09, Florian Weimer wrote:\n>>>>> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:\n>>>>>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC\n>>>>>> 9899:2011),\n>>>>>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,\n>>>>>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.\n>>>>>>\n>>>>>> Mostly of the definitions are composed based on POSIX conterparts,\n>>>>>> such as\n>>>>>> thrd_t (using pthread_t).\n>>>>>\n>>>>> I have skimmed the C11 discussion of these types, and C11 says that\n>>>>> mtx_t et al. are “identifiers”.  To me, this suggests they are\n>>>>> handles, just like pthread_t in the POSIX threads implementation.\n>>>\n>>>> My understanding is \"identifiers\" follow the definition from C11 6.2.1\n>>>> which does not exclude a tag/struct to represent it.\n>>>\n>>> I don't think “identifier” is used in this sense here.\n>>>\n>>> The standard says (7.2.6.1/4):\n>>>\n>>> “\n>>> The types are\n>>> \\begin{quote}\n>>>    \\verb|cnd_t|\n>>> \\end{quote}\n>>> which is a complete object type that holds an identifier for a\n>>> condition variable;\n>>> ”\n>>>\n>>> The “holds an identifier” suggests to me that this use of the term\n>>> “identifier” does not refer to the C language construct.  The\n>>> definitions in ISO/IEC 2382:2015(en) do not seem to be applicable,\n>>> either.\n> \n>> I find it quite inconsistent and improbable that the threads definition\n>> in C11\n>> standard is using a defined vocabulary in a different meaning than the rest\n>> of document.\n> \n> But how can a complete object *type* hold a C identifier?  The language does not support that.  We don't have call-by-name or anything like that.\n\nWhy do we need call-by-name to provide a complete identifier for C11 mtx_t\ntype? My understanding is we have the init functions to initialize the\nobjects and C11 threads avoid static initializers.\n\n> \n> So this usage doesn't make sense to me, so I assume that something else is meant here.\n> \n> I'm trying to get access to the WG papers on which the text is based. Maybe those illuminate what is meant here.\n\n\nSimilar objections were already raised in DR#493 [1], more specifically for\n\n\"1. What is the behavior of mtx_init() when called with a pointer to an object\ninitialized to all zeros (such as a mutex object with static storage duration)? \nAre such calls valid, or if not, must the function fail by returning thrd_error, \nor is its behavior unspecified, or perhaps undefined? (If it is the same as \ncalling it on an uninitialized object then how does one statically initialize a\nmutex?)\"\n\nThe committee discussion for this specific topic is aiming for:\n\n\"Problems with mtx_t\n\nThe semantics of copying a mtx_t are not specified, much like FILE §7.21.3p6.\"\n\n[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_493","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87136-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"GpTTtxwB\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycQ5N6h6qz9s82\n\tfor ;\n\tThu, 16 Nov 2017 00:22:00 +1100 (AEDT)","(qmail 70662 invoked by alias); 15 Nov 2017 13:21:53 -0000","(qmail 70340 invoked by uid 89); 15 Nov 2017 13:21:53 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=Hvra1bgpxvSIO2i5\n\ttf0GCTYRkycFiZSJP3aF4jGMY+NFvFfNDUDbllmRMOy9q1Atv6aiOKayR3CeL62m\n\tEgAQ6zpx3GMdSFZ3grsMILYr6b/Q8hMZ5qG9smdoQwvEt1WtjB3+72RvA/c5e7HG\n\tkkm7ueMGfu2c6FwOiDLScjKmxGM=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=aRRgRxp3WtxqLOCeVOvaKm\n\ttqyXE=; b=GpTTtxwBfjyeaqNzuM30b8vTj1pISR4qQJc7XMwvbibKVz/Gym2vIQ\n\tKXipPBtL3fECSvmSTQ5WXjwoLPDDTfEq2DxXSJALbDjWtar2aJH/ZnSaomDweXpA\n\tVaedBlvXlY7AbqTIyvMIvVUw9+5J6gR8U1k15npEj7vZ2LLSv71zk=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-3.1 required=5.0 tests=AWL, BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RCVD_IN_DNSWL_NONE,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=understanding","X-HELO":"mail-qt0-f170.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=dnKEe66pvKE1MB55ml2GCGOC9FsE3gxY7nEccVUppfc=;\n\tb=rSlX9vfabWll/2S9wYCPSRnMvLOdc3ylMpUAFfKVxEtMh56n/TmKtzUgCHusqWOUvA\n\t1DxMoWPNz2AtIlM2xbnXgtZ/tOynnLL7Hebwu7LAPplt3KxwefUMej3Zc7i9DIv1210A\n\tBSDGpZ5r54WZJdenglBiHewrHUQD85rOVpZ5huLj3fZGl0wRaFxi12Le6nJIPptp7n6n\n\ti0UcAR4r2t1CRH+40uiAqitIPSFUU4RoCtKkeRfm1ukNCPzyXri7A7wWtLEVhOUaHw9S\n\tnvQTEay0c6D0+d0UTs/AgaRP2E4fTCm2EBe4LF64Vak/inKGS9ZP7B2OgkyMY0+OUbzQ\n\tPGVA==","X-Gm-Message-State":"AJaThX4nVoB1/rWpTjUyr6ASEUZ6/+Mte/MIieoZ92xQsCimrjR2cQ+b\n\tl3rk80IyknUQUsR7R6v6WGMYvRj30q4=","X-Google-Smtp-Source":"AGs4zMYL222eEKWlVV/4AKaMPHIlxlJj3oqTOOIX6ryEox1zSZZBbOHoYc9vi5iH06TO6B8A+xltvA==","X-Received":"by 10.200.15.249 with SMTP id f54mr24313477qtk.216.1510752109654;\n\tWed, 15 Nov 2017 05:21:49 -0800 (PST)","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Florian Weimer ","Cc":"libc-alpha@sourceware.org","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>\n\t<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>\n\t<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>\n\t\n\t\n\t","From":"Adhemerval Zanella ","Message-ID":"<7b3aa01b-910f-8896-5dd3-fce1542669e9@linaro.org>","Date":"Wed, 15 Nov 2017 11:21:44 -0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit"}},{"id":1805026,"web_url":"http://patchwork.ozlabs.org/comment/1805026/","msgid":"<8e28cbb2-afd4-9b6b-60e5-0c8d74e641b0@redhat.com>","list_archive_url":null,"date":"2017-11-15T13:35:36","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":14312,"url":"http://patchwork.ozlabs.org/api/people/14312/","name":"Florian Weimer","email":"fweimer@redhat.com"},"content":"On 11/15/2017 02:21 PM, Adhemerval Zanella wrote:\n> \n> \n> On 15/11/2017 10:49, Florian Weimer wrote:\n>> On 11/15/2017 01:43 PM, Adhemerval Zanella wrote:\n>>>\n>>>\n>>> On 15/11/2017 10:03, Florian Weimer wrote:\n>>>> On 11/15/2017 12:22 PM, Adhemerval Zanella wrote:\n>>>>>\n>>>>>\n>>>>> On 15/11/2017 06:09, Florian Weimer wrote:\n>>>>>> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:\n>>>>>>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC\n>>>>>>> 9899:2011),\n>>>>>>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,\n>>>>>>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.\n>>>>>>>\n>>>>>>> Mostly of the definitions are composed based on POSIX conterparts,\n>>>>>>> such as\n>>>>>>> thrd_t (using pthread_t).\n>>>>>>\n>>>>>> I have skimmed the C11 discussion of these types, and C11 says that\n>>>>>> mtx_t et al. are “identifiers”.  To me, this suggests they are\n>>>>>> handles, just like pthread_t in the POSIX threads implementation.\n>>>>\n>>>>> My understanding is \"identifiers\" follow the definition from C11 6.2.1\n>>>>> which does not exclude a tag/struct to represent it.\n>>>>\n>>>> I don't think “identifier” is used in this sense here.\n>>>>\n>>>> The standard says (7.2.6.1/4):\n>>>>\n>>>> “\n>>>> The types are\n>>>> \\begin{quote}\n>>>>    \\verb|cnd_t|\n>>>> \\end{quote}\n>>>> which is a complete object type that holds an identifier for a\n>>>> condition variable;\n>>>> ”\n>>>>\n>>>> The “holds an identifier” suggests to me that this use of the term\n>>>> “identifier” does not refer to the C language construct.  The\n>>>> definitions in ISO/IEC 2382:2015(en) do not seem to be applicable,\n>>>> either.\n>>\n>>> I find it quite inconsistent and improbable that the threads definition\n>>> in C11\n>>> standard is using a defined vocabulary in a different meaning than the rest\n>>> of document.\n>>\n>> But how can a complete object *type* hold a C identifier?  The language does not support that.  We don't have call-by-name or anything like that.\n> \n> Why do we need call-by-name to provide a complete identifier for C11 mtx_t\n> type? My understanding is we have the init functions to initialize the\n> objects and C11 threads avoid static initializers.\n\nI read “holds” as “stores” in this context, as in:\n\n“\n\\begin{quote}\n \\verb|struct timespec|\n\\end{quote}\nwhich holds an interval specified in seconds and nanoseconds\n”\n\nI think using this wording in the context of identifiers is extremely \nsloppy because an object cannot store an identifier.\n\nI would have expected language like this if indirection is not required:\n\n“\nThe types are\n\\begin{quote}\n \\verb|cnd_t|\n\\end{quote}\nwhich denotes a complete object type which holds a condition variable;\n”\n\n>> So this usage doesn't make sense to me, so I assume that something else is meant here.\n>>\n>> I'm trying to get access to the WG papers on which the text is based. Maybe those illuminate what is meant here.\n> \n> \n> Similar objections were already raised in DR#493 [1], more specifically for\n> \n> \"1. What is the behavior of mtx_init() when called with a pointer to an object\n> initialized to all zeros (such as a mutex object with static storage duration)?\n> Are such calls valid, or if not, must the function fail by returning thrd_error,\n> or is its behavior unspecified, or perhaps undefined? (If it is the same as\n> calling it on an uninitialized object then how does one statically initialize a\n> mutex?)\"\n> \n> The committee discussion for this specific topic is aiming for:\n> \n> \"Problems with mtx_t\n> \n> The semantics of copying a mtx_t are not specified, much like FILE §7.21.3p6.\"\n> \n> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_493\n\nOh, this and the rest of the committee response assumes that the \nsynchronization objects are not just identifiers. I really wish this \nwas specified more explicitly.\n\nSo my concerns are apparently not shared by the committee.\n\nThanks,\nFlorian","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87137-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"kIm1Euv/\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycQPJ1rnZz9s82\n\tfor ;\n\tThu, 16 Nov 2017 00:35:47 +1100 (AEDT)","(qmail 126815 invoked by alias); 15 Nov 2017 13:35:42 -0000","(qmail 126803 invoked by uid 89); 15 Nov 2017 13:35:41 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=abodKH8VQckXQUGS\n\tfY8/2xFRCb/PhNg56BYl+zDW9xPBFYt6MDusbGOdb9HbIp7iYchz9IRjbShzBfvt\n\t6CJnrRaZt1ucTYWPpu0XeV1sj8gEUH+gMH/lZ3aH9K1gFTK9irHFRX32dvLvGZ7N\n\t6rvFcJy/0QCpA2caERoggVXJZLY=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=dQRumLjCAQsau2HorWho45\n\tXVKNU=; b=kIm1Euv/8T2P8w0ZI7Z7qV9yOodyMD+eFbaN/Qwqk7bZw/OHPwlZX9\n\te/7KFY1fr6Gh14JBasdF+EyoxUmK/wlJV1Y5V7ma8JGtmFDrgAIkyetfrx0MaxCA\n\tRlN34UESrOtAznTfLm0OaLqzjdYTgZ+zeC8TUDIPeoPcyen0lAb4Y=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.7 required=5.0 tests=BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RP_MATCHES_RCVD,\n\tSPF_HELO_PASS autolearn=no version=3.3.2 spammy=","X-HELO":"mx1.redhat.com","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Adhemerval Zanella ","Cc":"libc-alpha@sourceware.org","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>\n\t<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>\n\t<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>\n\t\n\t\n\t\n\t<7b3aa01b-910f-8896-5dd3-fce1542669e9@linaro.org>","From":"Florian Weimer ","Message-ID":"<8e28cbb2-afd4-9b6b-60e5-0c8d74e641b0@redhat.com>","Date":"Wed, 15 Nov 2017 14:35:36 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<7b3aa01b-910f-8896-5dd3-fce1542669e9@linaro.org>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"8bit"}},{"id":1805121,"web_url":"http://patchwork.ozlabs.org/comment/1805121/","msgid":"","list_archive_url":null,"date":"2017-11-15T15:46:07","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":66065,"url":"http://patchwork.ozlabs.org/api/people/66065/","name":"Adhemerval Zanella Netto","email":"adhemerval.zanella@linaro.org"},"content":"On 15/11/2017 11:35, Florian Weimer wrote:\n> On 11/15/2017 02:21 PM, Adhemerval Zanella wrote:\n>>\n>>\n>> On 15/11/2017 10:49, Florian Weimer wrote:\n>>> On 11/15/2017 01:43 PM, Adhemerval Zanella wrote:\n>>>>\n>>>>\n>>>> On 15/11/2017 10:03, Florian Weimer wrote:\n>>>>> On 11/15/2017 12:22 PM, Adhemerval Zanella wrote:\n>>>>>>\n>>>>>>\n>>>>>> On 15/11/2017 06:09, Florian Weimer wrote:\n>>>>>>> On 09/22/2017 10:26 PM, Adhemerval Zanella wrote:\n>>>>>>>> This patch adds the thrd_* definitions from C11 threads (ISO/IEC\n>>>>>>>> 9899:2011),\n>>>>>>>> more specifically thrd_create, thrd_curent, rhd_detach, thrd_equal,\n>>>>>>>> thrd_exit, thrd_join, thrd_sleep, thrd_yield, and required types.\n>>>>>>>>\n>>>>>>>> Mostly of the definitions are composed based on POSIX conterparts,\n>>>>>>>> such as\n>>>>>>>> thrd_t (using pthread_t).\n>>>>>>>\n>>>>>>> I have skimmed the C11 discussion of these types, and C11 says that\n>>>>>>> mtx_t et al. are “identifiers”.  To me, this suggests they are\n>>>>>>> handles, just like pthread_t in the POSIX threads implementation.\n>>>>>\n>>>>>> My understanding is \"identifiers\" follow the definition from C11 6.2.1\n>>>>>> which does not exclude a tag/struct to represent it.\n>>>>>\n>>>>> I don't think “identifier” is used in this sense here.\n>>>>>\n>>>>> The standard says (7.2.6.1/4):\n>>>>>\n>>>>> “\n>>>>> The types are\n>>>>> \\begin{quote}\n>>>>>     \\verb|cnd_t|\n>>>>> \\end{quote}\n>>>>> which is a complete object type that holds an identifier for a\n>>>>> condition variable;\n>>>>> ”\n>>>>>\n>>>>> The “holds an identifier” suggests to me that this use of the term\n>>>>> “identifier” does not refer to the C language construct.  The\n>>>>> definitions in ISO/IEC 2382:2015(en) do not seem to be applicable,\n>>>>> either.\n>>>\n>>>> I find it quite inconsistent and improbable that the threads definition\n>>>> in C11\n>>>> standard is using a defined vocabulary in a different meaning than the rest\n>>>> of document.\n>>>\n>>> But how can a complete object *type* hold a C identifier?  The language does not support that.  We don't have call-by-name or anything like that.\n>>\n>> Why do we need call-by-name to provide a complete identifier for C11 mtx_t\n>> type? My understanding is we have the init functions to initialize the\n>> objects and C11 threads avoid static initializers.\n> \n> I read “holds” as “stores” in this context, as in:\n> \n> “\n> \\begin{quote}\n>     \\verb|struct timespec|\n> \\end{quote}\n> which holds an interval specified in seconds and nanoseconds\n> ”\n> \n> I think using this wording in the context of identifiers is extremely sloppy because an object cannot store an identifier.\n> \n> I would have expected language like this if indirection is not required:\n> \n> “\n> The types are\n> \\begin{quote}\n>     \\verb|cnd_t|\n> \\end{quote}\n> which denotes a complete object type which holds a condition variable;\n> ”\n> \n\nI agree with you the wording could be more carefully picked in this case,\nbut the DR for C11 threads also points to a description you put.\n\n>>> So this usage doesn't make sense to me, so I assume that something else is meant here.\n>>>\n>>> I'm trying to get access to the WG papers on which the text is based. Maybe those illuminate what is meant here.\n>>\n>>\n>> Similar objections were already raised in DR#493 [1], more specifically for\n>>\n>> \"1. What is the behavior of mtx_init() when called with a pointer to an object\n>> initialized to all zeros (such as a mutex object with static storage duration)?\n>> Are such calls valid, or if not, must the function fail by returning thrd_error,\n>> or is its behavior unspecified, or perhaps undefined? (If it is the same as\n>> calling it on an uninitialized object then how does one statically initialize a\n>> mutex?)\"\n>>\n>> The committee discussion for this specific topic is aiming for:\n>>\n>> \"Problems with mtx_t\n>>\n>> The semantics of copying a mtx_t are not specified, much like FILE §7.21.3p6.\"\n>>\n>> [1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_493\n> \n> Oh, this and the rest of the committee response assumes that the synchronization objects are not just identifiers.  I really wish this was specified more explicitly.\n> \n> So my concerns are apparently not shared by the committee.\n\nWe had some discussion back in v3 about the opened DR for C11 threads [1].\nI has the assumption we had no block back then regarding base glibc\nimplementation on underlying POSIX one.\n\n\n[1] https://sourceware.org/ml/libc-alpha/2017-03/msg00461.html","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87153-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"T/SvpPF3\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycTHz47Vgz9s7F\n\tfor ;\n\tThu, 16 Nov 2017 02:46:23 +1100 (AEDT)","(qmail 60965 invoked by alias); 15 Nov 2017 15:46:16 -0000","(qmail 59164 invoked by uid 89); 15 Nov 2017 15:46:15 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=iyMkKQDzAg2tKgjT\n\tDNPeGtE8muPrC9oxErmm2EkI40KWX5NudljM1lg6OPHKpuNyM6rVUrRfRW5nnY4B\n\tOTdWShzJc9biSrHFcKYPQLKCDa+Fb9fiO8EwB6D8nZjb09wdS5gIZW8su1FmeUg0\n\tzo85XjjFRFruqbcHVz46xvDeagI=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=OEx6WnTk8GXOCqWU9TgcCk\n\tVXSkQ=; b=T/SvpPF3Pci7v8ik4cIudZphI9GbPbK6l+kRlTpWSAmO+wzp+Aiy0d\n\tdy68iL3A7PKh8yaib4osoaML+EWBwJK3KWLI4LR9ZRiLx1/UHLvHVIUMehNvyE/X\n\tjzVm7+0LkKMqsJEpakkDXStBlsb+2r8KKAO9C9CKBUz69O2Kp4pmU=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-2.5 required=5.0 tests=AWL, BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RCVD_IN_DNSWL_NONE,\n\tRCVD_IN_SORBS_SPAM,\n\tSPF_PASS autolearn=no version=3.3.2 spammy=","X-HELO":"mail-qt0-f176.google.com","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:subject:to:cc:references:from:message-id:date\n\t:user-agent:mime-version:in-reply-to:content-language\n\t:content-transfer-encoding;\n\tbh=5dMwlsFOOMo88t97CgS4RvxrsT+2393Y9FgJeFjiPlA=;\n\tb=hIHJu26Zi5ryKXB6vjBr/yL2o1YfqNSK381vBPz9DVgeod14lgXB34K+bZmqPLDy36\n\tOaTVSQiZzalA59WWkFoxZCSFr+/FU/Sfbrr9rDY1rRT8ntPcgWA/krSALuHE1VR6r/0S\n\tvk39zTR3x0DphdgVW+5ImDXoy6ijixHsKKxikq7syFaT9LFXe6PCS2H/9zyv0CtAqLTj\n\ttroDab+Cdy5po5/1KNBEsIQbkpXHy008fJlKhJwg1l2t53/+UYeYocXtJZTakfYtLWW6\n\tHyMscujAV+w1mPvJwgJA1UAVAjK5xlA51zokQFGw+4dzGq+OhhK4d4kCOt1akTuwejTE\n\taxkg==","X-Gm-Message-State":"AJaThX5jKWQC/a4RG9uE8B5FF1eALBtoNqRqdsZLBYANcAgI9P1cRQNi\n\tToJM/PJpTUfFeq3aX5Pb6cU0iYM7igA=","X-Google-Smtp-Source":"AGs4zMZILGLduJzvqJaC0yuspdPUiAeI0kL+NclJo6iiwY+vAgMNoCoI4z3fvqvltgJYh+sdVeZCNQ==","X-Received":"by 10.200.12.193 with SMTP id o1mr25160692qti.254.1510760771814; \n\tWed, 15 Nov 2017 07:46:11 -0800 (PST)","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Florian Weimer ","Cc":"libc-alpha@sourceware.org","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>\n\t<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>\n\t<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>\n\t\n\t\n\t\n\t<7b3aa01b-910f-8896-5dd3-fce1542669e9@linaro.org>\n\t<8e28cbb2-afd4-9b6b-60e5-0c8d74e641b0@redhat.com>","From":"Adhemerval Zanella ","Message-ID":"","Date":"Wed, 15 Nov 2017 13:46:07 -0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"<8e28cbb2-afd4-9b6b-60e5-0c8d74e641b0@redhat.com>","Content-Type":"text/plain; charset=utf-8","Content-Transfer-Encoding":"8bit"}},{"id":1805125,"web_url":"http://patchwork.ozlabs.org/comment/1805125/","msgid":"","list_archive_url":null,"date":"2017-11-15T15:50:25","subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","submitter":{"id":14312,"url":"http://patchwork.ozlabs.org/api/people/14312/","name":"Florian Weimer","email":"fweimer@redhat.com"},"content":"On 11/15/2017 04:46 PM, Adhemerval Zanella wrote:\n> We had some discussion back in v3 about the opened DR for C11 threads [1].\n> I has the assumption we had no block back then regarding base glibc\n> implementation on underlying POSIX one.\n\nI just want to minimize the risk that we implement something which is \nclearly incompatible with the standard. But it seems that at least as \nfar as the handle matter is concerned, the standard doesn't say what it \nmeans, and a non-handle implementation would be conforming, so that \nshouldn't be a problem for us.\n\nThanks,\nFlorian","headers":{"Return-Path":"","X-Original-To":"incoming@patchwork.ozlabs.org","Delivered-To":["patchwork-incoming@bilbo.ozlabs.org","mailing list libc-alpha@sourceware.org"],"Authentication-Results":["ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=sourceware.org\n\t(client-ip=209.132.180.131; helo=sourceware.org;\n\tenvelope-from=libc-alpha-return-87154-incoming=patchwork.ozlabs.org@sourceware.org;\n\treceiver=)","ozlabs.org; dkim=pass (1024-bit key;\n\tsecure) header.d=sourceware.org header.i=@sourceware.org\n\theader.b=\"fzSRgzQ2\"; dkim-atps=neutral","sourceware.org; auth=none"],"Received":["from sourceware.org (server1.sourceware.org [209.132.180.131])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3ycTP15nrWz9sBW\n\tfor ;\n\tThu, 16 Nov 2017 02:50:45 +1100 (AEDT)","(qmail 127017 invoked by alias); 15 Nov 2017 15:50:30 -0000","(qmail 126905 invoked by uid 89); 15 Nov 2017 15:50:29 -0000"],"DomainKey-Signature":"a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; q=dns; s=default; b=lhKVeCRM5brjtnCZ\n\t+zJpiXYiTh0svaaZsNA90K5lc7lfljDnwETNK11zDzi68SS+eWjQG+7sDUUoFqMu\n\tfDTy1yhWzA2LE10aQW2DItdeELnkSx9valinDxOTegKm1utB90ml/zbrDuSjyBsz\n\tqQ+g8jX4sMYDuW8kU5WcK1NhXJg=","DKIM-Signature":"v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id\n\t:list-unsubscribe:list-subscribe:list-archive:list-post\n\t:list-help:sender:subject:to:cc:references:from:message-id:date\n\t:mime-version:in-reply-to:content-type\n\t:content-transfer-encoding; s=default; bh=chIzZYWakaxO2cfI7Y8Kez\n\thKX6c=; b=fzSRgzQ2A7Umiq9I9yDaiBKH5V9l2kUodB8PtcCJqxPdJ/yi+OqyoZ\n\tlOmSfO5Vfo4hL4AcST/utBfswtAQ3PKUcrKoM8O9JJhRFIe/fhXjYJz8aCEG+97s\n\ttyCZDZQ+Iypc9YEkkzILab9oIqvJukpvxOfoBcmQisT/35m5k1gcU=","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":",\n\t","Sender":"libc-alpha-owner@sourceware.org","X-Virus-Found":"No","X-Spam-SWARE-Status":"No, score=-1.7 required=5.0 tests=BAYES_00,\n\tKB_WAM_FROM_NAME_SINGLEWORD, RP_MATCHES_RCVD,\n\tSPF_HELO_PASS autolearn=no version=3.3.2 spammy=risk","X-HELO":"mx1.redhat.com","Subject":"Re: [PATCH 1/8] nptl: Add C11 threads thrd_* functions","To":"Adhemerval Zanella ","Cc":"libc-alpha@sourceware.org","References":"<1506112024-22601-1-git-send-email-adhemerval.zanella@linaro.org>\n\t<1506112024-22601-2-git-send-email-adhemerval.zanella@linaro.org>\n\t<8f17b389-ffda-4add-f8f8-8acd7be96c60@redhat.com>\n\t<0234dc48-18ae-8d79-1d9f-23482061c16b@linaro.org>\n\t\n\t\n\t\n\t<7b3aa01b-910f-8896-5dd3-fce1542669e9@linaro.org>\n\t<8e28cbb2-afd4-9b6b-60e5-0c8d74e641b0@redhat.com>\n\t","From":"Florian Weimer ","Message-ID":"","Date":"Wed, 15 Nov 2017 16:50:25 +0100","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.4.0","MIME-Version":"1.0","In-Reply-To":"","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Transfer-Encoding":"7bit"}}]