From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 6F6533858414 for ; Wed, 15 Sep 2021 14:34:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6F6533858414 IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A7v+nbq9nKpZVNl73rYZuk+DnI+orL9Y04lQ7?= =?us-ascii?q?vn2ZbSYlF/Bw8Pre+MjztCWE6wr5N0tQ/+xptMG7LE81ifVOi7X5UY3NYOCegg?= =?us-ascii?q?eVxeJZnOzfKkPbcBEWrdQz6U4IScEXNDSXNzhHZK3BkWuF+rgboeVviJrY/Nvj?= =?us-ascii?q?8w=3D=3D?= X-IronPort-AV: E=Sophos;i="5.84,326,1620684000"; d="scan'208";a="393064823" Received: from nat-eduroam-36-gw-01-bso.bordeaux.inria.fr (HELO begin) ([194.199.1.36]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2021 16:34:28 +0200 Received: from samy by begin with local (Exim 4.95-RC2) (envelope-from ) id 1mQVzX-00FDFB-CZ; Wed, 15 Sep 2021 16:34:27 +0200 Date: Wed, 15 Sep 2021 16:34:27 +0200 From: Samuel Thibault To: Sergey Bugaev Cc: bug-hurd , libc-alpha@sourceware.org Subject: Re: [PATCH htl v3 2/5] htl: Move thread table to ld.so Message-ID: <20210915143427.4djiwiucrgz65pru@begin> Mail-Followup-To: Sergey Bugaev , bug-hurd , libc-alpha@sourceware.org References: <20210907133325.255690-1-bugaevc@gmail.com> <20210907133325.255690-3-bugaevc@gmail.com> <20210914232700.sdjzmsfwbs626wqz@begin> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2021 14:34:30 -0000 Sergey Bugaev, le mer. 15 sept. 2021 17:14:00 +0300, a ecrit: > > Even if for now they are actually locks and not rwlocks, the day we fix > > that the rwlocking of dl_pthread_threads_lock will get fixed alongside. > > May I ask, why are rwlocks unimplemented? Is it just that nobody has > done the work, This, yes, as usual :) > And HTL of course has its own rwlocks implementation. Would it make > sense to me to spend some time to try and write a __libc_rwlock based > on them, or are there some obstacles? Well, at some point we'll probably want to just do like nptl and simply #define __libc_rwlock pthread_rwlock, so it's probably not worth spending time on making a separate __libc_rwlock implementation, and rather spend it on making pthread_rwlock use gsync, like was done for pthread_mutex and sem, and then we can just #define __libc_rwlock pthread_rwlock. Samuel