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: Some experience with the igc branch Date: Fri, 27 Dec 2024 09:57:47 +0200 Message-ID: <867c7ly2v8.fsf@gnu.org> References: <87o713wwsi.fsf@telefonica.net> <87ldw6as5f.fsf@protonmail.com> <86o7112rnq.fsf@gnu.org> <867c7p2nz4.fsf@gnu.org> <861pxx2lh7.fsf@gnu.org> <86ldw40xbo.fsf@gnu.org> <86a5cj2a0e.fsf@gnu.org> <867c7n28sf.fsf@gnu.org> <877c7n962e.fsf@gmail.com> <8634ib24gp.fsf@gnu.org> <875xn75w7u.fsf@gmail.com> <86ttaryn1x.fsf@gnu.org> <877c7mzxbw.fsf@gmail.com> <861pxuzt61.fsf@gnu.org> <87wmfmy6mq.fsf@gmail.com> <86ttaqxybk.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6141"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eller.helmut@gmail.com, gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 27 08:58:37 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 1tR5Ez-0001Re-Do for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Dec 2024 08:58:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tR5EH-00064C-1w; Fri, 27 Dec 2024 02:57:53 -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 1tR5EF-0005zv-1J for emacs-devel@gnu.org; Fri, 27 Dec 2024 02:57:51 -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 1tR5EE-0001Fu-39; Fri, 27 Dec 2024 02:57:50 -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=lFmlHlWCkpVUYf53WJOsFphDgJz2lAEtoIErYGc1SJY=; b=cWclGUvu0/5M T5Wh8WHYxqfkoedDZoylcgwXnvF1vPhgQBhYMoP4kD4AHXA/zaHHQHM5f4BSR1PlnQ6DotK06BRrg Y3W8dUsU1+2BlWCDd3991gV9kF+/nKkC6VM5nSCcyhX4EyZOhwHlWasTIPR/k9dR/m4KsEu7IoXZs sGu3pr+o8kV/N+MABRiyajpbQV274qtNB70bg/1Eo4x3TnkLRUi4nr9K6okaEDs+c0yAvKvFLKoCB A9IanWD1m/FzD9AtOtFCwS42e5jOVpuBz4RBHvGJJghtcD02vt59hFhH1FyvwApPrSDGzG+OiXHgP USrfLpWiwkh7XhVqeCOcKA==; In-Reply-To: (message from Paul Eggert on Thu, 26 Dec 2024 15:29:29 -0800) 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:327175 Archived-At: > Date: Thu, 26 Dec 2024 15:29:29 -0800 > Cc: gerd.moellmann@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org > From: Paul Eggert > > On 2024-12-26 07:23, Eli Zaretskii wrote: > >> From: Helmut Eller > >> I thought deliver_process_signal was there to forward signals to the > >> main thread but you certainly know better what it does and doesn't. > > > > Actually, we need Paul Eggert to chime in, because he knows much more > > about this than I do. We have arrangements for when a signal is > > delivered to a thread, but I think Paul said this should rarely if > > ever happen. > > Helmut's right: deliver_process_signal arranges for the handler to be > called in the main thread even if the thread was delivered to some other > thread. Is this true also on Posix systems other than GNU/Linux, though? > And to some extent you're right, too, on GNU/Linux, where historically > this rarely happened unless the signal was blocked in the main thread. > That part of the Linux kernel has evolved, though, and I don't know > whether this is still true. However, whether it's true shouldn't affect > the correctness of deliver_process_signal. Can you tell what happens during the short window between the signal being delivered to a thread and until it is redirected to the main thread? Specifically, are the threads other than the one which git hit by the signal still running until pthread_kill stops the main thread? This could be important for us to understand what could happen if the signal hits the MPS thread or another non-Lisp thread in Emacs. Btw, init_signals initializes main_thread_id to the main thread of the Emacs process, and AFAICT this is never changed during the session. So what happens if, when the signal arrives, the main thread is stuck in acquire_global_lock trying to take the global lock while some other Lisp thread runs? AFAIU, this means, among other things, that our profiler cannot profile non-main Lisp threads, because SIGPROF will always sample the state of the main thread?