From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Mon, 30 Dec 2024 17:49:09 +0000 Message-ID: <87jzbhxdt0.fsf@protonmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <8734i5o6wc.fsf@gmail.com> <87cyh9mpn5.fsf@gmail.com> <874j2l1hei.fsf@protonmail.com> <874j2lmd37.fsf@gmail.com> <87msgdkt29.fsf@gmail.com> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30903"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= , Eli Zaretskii , spd@toadstyle.org, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 19:29:49 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 1tSKWT-0007re-M8 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 19:29:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSKW5-0004Bg-El; Mon, 30 Dec 2024 13:29:25 -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 1tSJtH-0002TN-5o for emacs-devel@gnu.org; Mon, 30 Dec 2024 12:49:19 -0500 Original-Received: from mail-10630.protonmail.ch ([79.135.106.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSJtD-0007rl-9D for emacs-devel@gnu.org; Mon, 30 Dec 2024 12:49:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735580952; x=1735840152; bh=GN57uJE50je+aoMQHOejKDd6yd94OtygkxRUvfKRcdE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=pOOteMEMCl8IsRfhjGmq5RXv1twE950Ve3i/HAKJedq7Rt8ewFv+6uN2elYqzd9k1 PfxfBp6vy6GDV8rsY+cZUuY0qXC1LqSklWQBx9dxnT+qyVuFkIPDF6lc8yhg72OYHU 9vawRynpFugLD8PyMI9mXGQrXsjINODlrf0FtAsMGdrB7xJ4qVbdwPjJseuR81flMQ sJo7j7souQrX3cuVwE0bavPFTvxJm/q/Xt7JlIO6HcMZFVJIWpvebK7c9pMudDN4Gg aFpFtWrMocBreD/87ccSIYz+d296cqpAqporgKL3VvRtkzcYsdCP64lTpBkIkSX5gH MT+Euo7KcmU4A== In-Reply-To: <87msgdkt29.fsf@gmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 570935d6a4d8347fd52b94a7f2503b7208e9f42b Received-SPF: pass client-ip=79.135.106.30; envelope-from=pipcet@protonmail.com; helo=mail-10630.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Mon, 30 Dec 2024 13:29:22 -0500 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:327461 Archived-At: "Helmut Eller" writes: > On Mon, Dec 30 2024, Gerd M=C3=B6llmann wrote: > >> Bool (LockIsHeld)(Lock lock) >> { >> AVERT(Lock, lock); >> if (pthread_mutex_trylock(&lock->mut) =3D=3D 0) { >> Bool claimed =3D lock->claims > 0; >> int res =3D pthread_mutex_unlock(&lock->mut); >> AVER(res =3D=3D 0); >> return claimed; >> } >> return TRUE; >> } >> >> There might be a small window after pthread_mutex_trylock and being back >> in the signal handler. Can anything happen in this window? >> >> If no other Emacs threads are running, and the Emacs thread is in the >> signal handler, we can trust the "false" from the mps_arena_busy. > > Theoretically, a signal handler could interrupt the Emacs thread and > lock the mutex without unlocking it. I don't think that's a problem. Here's why: We'd have to call the POSIX police. I believe it's a conscious POSIX decision not to allow hand-over of locks from one thread/signal handler (those can't even call _trylock) to another; this is relevant to the priority inversion scenario (if we had a "background" GC thread running at a lower priority (whatever that would mean? E-core? Different power-performance prefs? Throttled?), the main thread would have to find a way to boost its priority (move it to a P-core, unthrottle, whatever) if we're actually waiting for it to release the arena lock. One way would be to take over its lock (easy) and stack (hard) while retaining thread settings, but POSIX decided we don't want to do that. Thank you, POSIX (in this case)). On inhomogeneous systems (almost everything you can buy today, ESP32 to server CPU), "priority inversion" can happen with just two threads, since priority is no longer defined by access to a single or several identical cores. But anyway, POSIX prohibits it, glibc on GNU/Linux doesn't support it, I'm not aware of any other systems making that useful, certainly not for Emacs. > That would be a very unusual signal handler. I hope no other surprises h= appen in signal handlers. longjmp-based green threads? (MPS currently assumes a simple linear stack, gcc can produce split-stack code, getting that combination to work would be good; I can dig up the patch for enabling it for the old GC). Pip