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: Some experience with the igc branch Date: Sun, 29 Dec 2024 17:14:44 +0000 Message-ID: <87o70u2z07.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <87ldw15h6s.fsf@protonmail.com> <86a5chw20u.fsf@gnu.org> <871pxt5b8u.fsf@protonmail.com> <865xn3sn2e.fsf@gnu.org> <871pxrecy7.fsf@protonmail.com> <86pllbqakj.fsf@gnu.org> <87frm6d5pa.fsf@protonmail.com> <8634i6r3zw.fsf@gnu.org> 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="31747"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 29 18:39:03 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 1tRxFm-00085m-7D for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Dec 2024 18:39:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRxEz-0007h8-Cg; Sun, 29 Dec 2024 12:38:14 -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 1tRwsU-0004Oe-JT for emacs-devel@gnu.org; Sun, 29 Dec 2024 12:14:58 -0500 Original-Received: from mail-10631.protonmail.ch ([79.135.106.31]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRwsP-0005xN-4X for emacs-devel@gnu.org; Sun, 29 Dec 2024 12:14:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735492488; x=1735751688; bh=XgAE4Pn5Wvt1lR6G4ttn049TXxXeGILXYtv/Bk3DcSQ=; 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=xyEcQtjggeng+854TAe8SCl4WFUj4IHxlKNhIiJwOkaOYRZ5WAsIOQIsJ30u47fhD 9uemYRUSuPRUIpNpvrZPIs6di6Jac2l64+0LJ/TqXnH7Zv9bY35qYu99h81XYEJN3E 9YXG6tvQt0l6o9r4YSh0M00N/vjrvTR4G1FXYIpZN/MnSn2s7HrtBLGVbOUzfh6Eh/ XD25f9QlhborZv/fY6GPr8fbbVl1N1mUeQHLR67fHsHDXNX/exmwQEknysGHjXdQoS joMr7kn8tagpfoI8UALaVTEuECCEIfF8tsFtxZ+hpLm9bJ3aiXwtk7nwPyV96ctw4T dt5CJYUWJQb3g== In-Reply-To: <8634i6r3zw.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: bcd62c5def91fbe4f0ff98c30a2c679dca161920 Received-SPF: pass client-ip=79.135.106.31; envelope-from=pipcet@protonmail.com; helo=mail-10631.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.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 29 Dec 2024 12:38:05 -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:327353 Archived-At: "Eli Zaretskii" writes: >> Date: Sun, 29 Dec 2024 12:39:53 +0000 >> From: Pip Cet >> Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller= .helmut@gmail.com, acorallo@gnu.org >> >> >> Instead, we call the SIGSEGV handler directly on the other thread, >> >> passing in the same siginfo structure. >> > >> > How can we call the SIGSEGV handler directly from another thread? And >> >> It's a C function. We call it. > > We need to know its name or its address to do that. It is not our > function. sigaction gives us the pointer. >> > how will that thread know it needs to call the handler in the first >> > place? >> >> We'd like to just use pthread_cond_signal, but to be POSIXly correct we >> need to do so from another thread. > > Ouch! There are ways around that, but I'm liking this aspect less and less. Effectively, macOS and Windows run the exception handler with signals blocked (Windows doesn't have any; the macOS exception handling mechanism blocks signals on both threads, IIUC). If we do the same on POSIX, by adding all Emacs signals to the sigmask for the MPS SIGSEGV action, it should be safe to leave it in place. (We would still need to leave the MPS signals unblocked, of course). I *think* that's still safe, but I have to think about it some more. As for the current scratch/igc code, we could use it and fix it one signal at a time. SIGIO/SIGPOLL don't need to be delayed SIGPROF doesn't need to be delayed if it simply records "in GC" SIGCHLD: already fixed by Helmut. If that fix is unacceptable, we can clear delayed SIGCHLD signals before we create a new process, which would mean Emacs doesn't use extra PIDs. SIGALRM: difficult. Does this need to run on the main thread? I'll have to look at the code. SIGINT, SIGUSR*: very difficult. >> >> > how will it know which MPS function to call? >> >> >> >> The MPS SIGSEGV handler is obtained by calling sigaction. >> > >> > That's unreliable: it assumes that no one else calls sigaction after >> > MPS, or changes the chain of handlers in some other way. >> >> It merely assumes that any such modifications call our signal handler >> with the right arguments, which is precisely what MPS assumes anyway. > > Sorry, I don't follow. Let's delay this particular discussion until we actually have decided the other problems aren't severe enough to kill the allocation thread proposal? Pip