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 12:39:53 +0000 Message-ID: <87frm6d5pa.fsf@protonmail.com> References: <87o713wwsi.fsf@telefonica.net> <8734ia79jq.fsf@protonmail.com> <86pllexwru.fsf@gnu.org> <87ldw15h6s.fsf@protonmail.com> <86a5chw20u.fsf@gnu.org> <871pxt5b8u.fsf@protonmail.com> <865xn3sn2e.fsf@gnu.org> <871pxrecy7.fsf@protonmail.com> <86pllbqakj.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="21479"; 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 14:34:22 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 1tRtQy-0005Or-J0 for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Dec 2024 14:34:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRtQC-00008n-5g; Sun, 29 Dec 2024 08:33:32 -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 1tRsaY-0001DZ-Dz for emacs-devel@gnu.org; Sun, 29 Dec 2024 07:40:10 -0500 Original-Received: from mail-10629.protonmail.ch ([79.135.106.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRsaU-0000jy-Fp; Sun, 29 Dec 2024 07:40:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735475998; x=1735735198; bh=h6R4mdQiUGFw/Mu8kHCX8HAiGn4px9+HqzckAULEzTw=; 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=NhrEVHJqvSZj6ZeFPBaSLV3Zlne7p/tWi25RQAx7C8Mp3/Y082Byk1OpFhO3AQOqx VOD84IxZ40v0kkybl68q0rVXPq1PZkSEPNo+MKZIFmmMgdQUBMFmSiWJHV+0u74l2Z JjHJbNVlRtM8bNQhx/8HWPjBCmSIVecCg2EpIzyx+JJxmIqxWNjywxkaPPrtvBSy23 RS0faQhFxpC61Xy+4eTVmEjBLJwia4KcYW8PweAFaij5FpsCc9cEfuaQy9V0CIvDkH qsifahNLDyt2vbVPuKRTPGwqZAe3CrafN/3nl6wwnRjkv3UAl8+8/koZEHoGeUCOX4 7xXfcybJOAiJQ== In-Reply-To: <86pllbqakj.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8195dc3865fa3459891bfa5a16965fed56017e5b Received-SPF: pass client-ip=79.135.106.29; envelope-from=pipcet@protonmail.com; helo=mail-10629.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_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 08:33:24 -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:327333 Archived-At: "Eli Zaretskii" writes: >> Date: Sat, 28 Dec 2024 21:05:43 +0000 >> From: Pip Cet >> Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller= .helmut@gmail.com, acorallo@gnu.org >> >> "Eli Zaretskii" writes: >> >> > By >> > contrast, under your proposal, MPS should be called from a separate >> > thread. However, the way we currently process signals, the signals >> > are delivered to the main thread. So we should install our own >> > SIGSEGV handler which will run in the context of the main thread, and >> > should somehow redirect the handling of this SIGSEGV to the MPS >> > thread, right? >> >> Correct. >> >> > So now the main thread calls pthread_kill to deliver >> > the SIGSEGV to the MPS thread, >> >> No, that wouldn't work. We need the signal handler to have access to >> the siginfo_t data, and pthread_kill provides no way to include that >> information. >> >> 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. > 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. >> (My original code simply accessed a byte at the fault address; however, >> reading the byte isn't sufficient, and writing it risks exposing >> inadmissible intermediate states to other threads, so now we call the >> sa_sigaction function directly). >> >> >=C2=A0but what will the MPS thread do with that? >> >> Call the MPS SIGSEGV handler, which knows what to do based (currently) >> only on the address. >> >> > 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. > Also, on MS-Windows MPS doesn't use a signal handler (because there > are no signals on Windows, really). It uses an exception handler, and Can exception handlers be interrupted by emulated signals running on the same stack? If they can't, we don't need to worry about this part for Windows. If they can, though, back to the drawing board :-) > But if this is not relevant to those conditions (which I frankly don't > understand why they are needed), then we could stop arguing about that > aspect. We still need to decide whether there should be a way for code to assume no GC can happen. If it should be possible, we need to spell out when that assumption can be made. Pip