From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Mon, 30 Dec 2024 10:29:55 +0100 Message-ID: <8734i5o6wc.fsf@gmail.com> References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <86ed1rswup.fsf@gnu.org> <87h66loc17.fsf@gmail.com> <878qrxoayj.fsf@gmail.com> 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="38762"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , spd@toadstyle.org, pipcet@protonmail.com, emacs-devel@gnu.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 10:31:08 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 1tSC7A-0009u8-BQ for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 10:31:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSC6L-00084y-Kg; Mon, 30 Dec 2024 04:30:17 -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 1tSC67-00084T-Ia for emacs-devel@gnu.org; Mon, 30 Dec 2024 04:30:03 -0500 Original-Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSC64-0001Sa-G4; Mon, 30 Dec 2024 04:30:03 -0500 Original-Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d122cf8dd1so15465220a12.2; Mon, 30 Dec 2024 01:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735550997; x=1736155797; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=pEDzwB/OLl1g3sotxN9OIiu7pu3s6KbGnbAs1LC5bwU=; b=LJMWSLMWFdoq+zov4ElBv7RgmW0THelu0Ej9xjZ1TMz34ndUhPFp5ignLhG9WTKxrD Rs8dFEDhHe6L0dP49gRIfxTxhYgfdGmWXz7ovpcqGFiSPk4KHAXpr2xcER+ahSN/kfMG AMOjGfBJyEOEC82hk2jM1kFtiaOZhCfOUSiS1VpiU/djNYSTo+iM1CjgZCFWqD9BDEEN oOeo25Fay0rZbP0Z4SCwGub2r1iJmlR5fprbzKqTRa+1wjMb4KzcjpnG5Px6P45K/VyZ 39On16pNE3ybYOOJZVgsPDPJJJo8y8WJEwhJWpcS1SPMVEDhUw4LI5rKFGLQvVW5eX1/ KJVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735550997; x=1736155797; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=pEDzwB/OLl1g3sotxN9OIiu7pu3s6KbGnbAs1LC5bwU=; b=qB6Vo7CPDf33P4UszsQcWfwfWet5sIcI/GCr+KdlHfrWlEqhOFfRK4v2unRK2c5fsb Yg95N6gmTtzb90qbJbQiBzOXKZ0SCCqa1iY7VpzPHtMPlt3Ibex9oHLOosZhuPQEkaD1 vx1v2KbFsYWO546loDAGntKxU2DXJPF0Ec+UePDN4/l6yEvSGxIMkY3k4WkP3kknMEbv OzLYBZ9rH56vrqCJyE25V3vaheEmKa1gAi9a9Ug5eAv2y5cxz5LTnerEzfHW8HrpFEyA zitYccXg/pnoz4tIBZNozM4DsNVS4lnrEOBiaIPX1Lne98U4nenbGGLR7MNPv/t2KTIb pqZQ== X-Forwarded-Encrypted: i=1; AJvYcCWLjgOCeuAp8ocfkymHoP5Ms0dnXQqiEdTYyVTMIrQAFlfAgMrmVbz8spoYQ4j4i/bt+D7Qc4Qs8OPbcA==@gnu.org X-Gm-Message-State: AOJu0Yxd8q0JhSSIyMZ0ao6mK+c/FDySc9ifwbgCWOyZTUCuJhK7668w 9YjyrcCQcMOYFo+r6oO8oU6W5G+QUtAal+9Ic8C9j+Ks2E9Xmmi9ebosq1LY X-Gm-Gg: ASbGncs4CU5fRL1HW60fikVJ4I27eZ84FLUIS1jDv685T6NUmT/RNl05SM7O2+7Zd0T 4q1SoKRGQ5lmhRc9PJiPikuPQC0e6zZcDuMESBsikbM2+/U2v9p0qsyJcoUN0UxYQvuSJfheA5h hRW9SRZU1xscwVdoe9rmXklB99YJqP9OrXte/gKToTW3EMUbSL0NdDuAhU46Yvy7QjCl1c1WjMZ 6pcPTyHP9IajCvKE9FDFEHrISp45Rg6PZvTQAxCs5r1bIQQd5t72co= X-Google-Smtp-Source: AGHT+IGkmK8F81c62lxJBqEkGz4GFwbkab68v8ViOCyBLpCabj/UjK6yo3s4FGpxNb3TyVfeMbNfMw== X-Received: by 2002:a05:6402:4306:b0:5d3:d733:7ad4 with SMTP id 4fb4d7f45d1cf-5d81dd83b9emr27636378a12.3.1735550996672; Mon, 30 Dec 2024 01:29:56 -0800 (PST) Original-Received: from caladan ([31.177.115.143]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d80676f218sm14921689a12.26.2024.12.30.01.29.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 01:29:56 -0800 (PST) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?= =?utf-8?Q?s?= message of "Mon, 30 Dec 2024 09:47:54 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::52b; envelope-from=eller.helmut@gmail.com; helo=mail-ed1-x52b.google.com 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:327396 Archived-At: On Mon, Dec 30 2024, Gerd M=C3=B6llmann wrote: [...] > But something else: Given what I now believe, I think I want to > understand better (a bit) why everything appears to work just fine on > macOS, with signals. Could you perhaps check if I'm off? MacOS only. > > In normal operation, there are only ever 2 threads running. An Emacs > thread is interrupted by a signal and lands in a signal handler, the > MPS port thread keeps running. > > In the signal handler, hitting barriers is handled by the MPS port > thread. Consistency of Emacs's state is a problem the signal handler has > to deal with, Agreed. > consistency of MPS' GC data is a problem that hopefully > MPS handles, and it seems to work. My interpretation of this design document[*], is that MPS's arena lock protects most of MPS entry points. There are a few (e.g. mps_reserve and mp_ld_add) that don't claim the arena lock and for those it's the burden of the client to call them in a thread safe way. For us this probably means: don't call them in a signal handler. The main entry point that we want to call in the signal handler is the SEGFAULT handler (not sure how this works on MacOS). The fault handler claims the non-recursive arena lock. So, in the signal handler we should not hold the lock while hitting a barrier. > I think I understand that, except when the Emacs thread is interrupted > while in MPS code, which happens for allocation points running out of > memory and mps_arena_step (idle time). Hmm, is that sentence incomplete? I don't quite understand it. > Do you agree so far? If yes, I'd bite the bullet and look at the MPS > code for macOS how that is done, if it's done. Yes, mostly. Helmut