From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: SIGPROF + SIGCHLD and igc Date: Sat, 28 Dec 2024 21:00:07 +0200 Message-ID: <8634i7skeg.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87a5ch5z1b.fsf@gmail.com> <87plld5pev.fsf@protonmail.com> <87ed1t6r34.fsf@gmail.com> <875xn46s6z.fsf@gmail.com> <86bjwwulnc.fsf@gnu.org> <877c7jlxsu.fsf@gmail.com> <86frm7sx4d.fsf@gnu.org> <87a5cfoivh.fsf@gmail.com> <867c7jsoat.fsf@gnu.org> <8734i7of3h.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30792"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 20:01:10 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tRc3h-0007p7-88 for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 20:01:09 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRc33-0003rk-7f; Sat, 28 Dec 2024 14:00:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRc2w-0003qt-Tl for emacs-devel@gnu.org; Sat, 28 Dec 2024 14:00:23 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRc2o-0004yy-Ea; Sat, 28 Dec 2024 14:00:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=cJf8u7MSDTNbFaaAKE9Ovcoz1AxTHjQrUoJl3PgHMkQ=; b=Ogj7fNyTyXGf EinULadxs5CmNIEN71BKhbNpo1zpwHqVnU6gASimmHjyvF+8t0+pxJAgUy9qV1/jP6ow+qLhQxKYH YJaFVVoU7j9s9U5JLP79s6Er5vQ1XAXXNlVhQsFJadF0YyGS5/yfpl76E9iOo9CoHSLy8vLgchXYx kkDWNS6b/wCrOuCT52egG6wytljJ2B7GW15OgKJqxM23gmKFiJT6yDqITniU0JHPYDJn8TK4W1ekK 5zT2XZXrHo+qK9tXrlXtL9l/Jk+BNFRWprg9dH8zpSvYSvdX2dnNsUq33DalWPntgc1PI6ZgDTWFr gNsdfX7IpbRkedXUl3GqPg==; In-Reply-To: <8734i7of3h.fsf@gmail.com> (message from Helmut Eller on Sat, 28 Dec 2024 19:08:18 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327284 Archived-At: > From: Helmut Eller > Cc: pipcet@protonmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, > emacs-devel@gnu.org, acorallo@gnu.org > Date: Sat, 28 Dec 2024 19:08:18 +0100 > > On Sat, Dec 28 2024, Eli Zaretskii wrote: > > >> If two threads are claiming a the same non-recursive lock concurrently, > >> then it's not an error. > > > > Oh, so you are saying that taking the lock twice is a fatal error only > > if that is done from the same thread? Is that known for certain? > > Ahem, now you're making be nervous. I'll show the implementation > before I say something stupid: > > /* LockClaim -- claim a lock (non-recursive) */ > > void (LockClaim)(Lock lock) > { > int res; > > AVERT(Lock, lock); > > res = pthread_mutex_lock(&lock->mut); > /* pthread_mutex_lock will error if we own the lock already. */ > AVER(res == 0); /* */ > > /* This should be the first claim. Now we own the mutex */ > /* it is ok to check this. */ > AVER(lock->claims == 0); > lock->claims = 1; > } I guess they use PTHREAD_MUTEX_ERRORCHECK to get the error? Anyway, the MS-Windows implementation uses EnterCriticalSection, which allows a thread to call it any number of times after the first call succeeded, so they must be using something else on Windows to detect multiple locks by the same thread, maybe the count of claims or something? > > > Are we sure MPS must take the lock before it can stop registered > > threads? > > Now that's a question for the MPS mailing list. Right.