From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Gerd_M=C3=B6llmann?= Newsgroups: gmane.emacs.devel Subject: Re: igc, macOS avoiding signals Date: Tue, 31 Dec 2024 15:15:04 +0100 Message-ID: References: <799DDBC5-2C14-4476-B1E0-7BA2FE9E7901@toadstyle.org> <87h66loc17.fsf@gmail.com> <878qrxoayj.fsf@gmail.com> <8734i5o6wc.fsf@gmail.com> <87cyh9mpn5.fsf@gmail.com> <874j2l1hei.fsf@protonmail.com> <874j2lmd37.fsf@gmail.com> <87msgdkt29.fsf@gmail.com> <86h66lnjrt.fsf@gnu.org> <868qrxnfrw.fsf@gnu.org> <87a5ccl2zx.fsf@gmail.com> <86msgcm1nm.fsf@gnu.org> 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="19506"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: eller.helmut@gmail.com, pipcet@protonmail.com, spd@toadstyle.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 31 15:16:01 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 1tSd2O-0004ta-UT for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Dec 2024 15:16:01 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSd1e-0005iQ-Ky; Tue, 31 Dec 2024 09:15: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 1tSd1c-0005hZ-TA for emacs-devel@gnu.org; Tue, 31 Dec 2024 09:15:12 -0500 Original-Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSd1Y-0001jR-HW; Tue, 31 Dec 2024 09:15:10 -0500 Original-Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5d3f28881d6so14345091a12.1; Tue, 31 Dec 2024 06:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735654506; x=1736259306; 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=dPKnC0Z/6pmxIJhZlYlaARvUnVTEyGvXWPU61zmyE6U=; b=H4pnTtcUsOvXAheZrhbeH0gEtk6AtdkglNKYFpbJqgoZwaPd1BMWL8eN6obICTWmPt zOnPgtj9uvC7+SAEIAKWj+fHS/pwcibWnm/hh8w+KbJprduoq9G6XMkn1tYk69Qkbw2K XwflcJ8Gwmz/03EAm88eyGsLoQyf25egIjwmf9Tdvz0MDKy4SSoOXuyPxbfmgKH8/yM3 YxU0EYGoBKPAzFTNk+2bYwyJpdB51NSIRCNNpqwX4t3/sJnrjjMhHsTv6aam9rLUPGlX zMXFve1sRiLqieGZGLamXiheshstA37MoIPpXdWDeuadnXMTEXlJvrZGUjqzQejisfUg vaoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735654506; x=1736259306; 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=dPKnC0Z/6pmxIJhZlYlaARvUnVTEyGvXWPU61zmyE6U=; b=tgYxyONvI/G429irOczkYoO24Muz5sPRwRwM0tveA8Uu+mOyzgwXsOGwTOcSEgMaxt sccp/oSOQ3NgyIBlYeF2Dk0Hwd7xeIy2Gnvx+rAWb3l/ZxV42n1zBUYw5ARzkOZOpJo5 AKdumMRjQ8wJ0XzahUjeLMaMzQO/SOa2xlNKkO92R4ti5sO+TQy5QzQMs0JnRNSJHvCp Cnz/atz67UKpqr+y9y2cKsKYhF9pkwSuaXMSsw6tEke0PZ2vvr64mjDxI4lA3YCq9AYx tCoeajv/d+jI4rKUGLFhGW6q1Dg/vk0Res1lLUYORf2WvCoICQ8mcj4Tz+5KsQFbZIAw zkVw== X-Forwarded-Encrypted: i=1; AJvYcCUlTq3MLIRJeOyNAzcbQc0oKClH0UTHpsExTLlqO+hVy7De5qjExLfdkYi10nA4PIQCZI4+cLTBM0+RxA==@gnu.org X-Gm-Message-State: AOJu0Yz9S/rkmpE8CGos/4NtOIlMkpf7Kp6mGX/VEwXL/fqrpkP2ryur QUtfb0wAvP+dSkEGq5GR7zalrllCwnh1ZALg8xFHh4iuzUIihBAIZdd+Aw== X-Gm-Gg: ASbGncvf7yEmxR9egpO4s8czY+tQ8ZorzdCd1U5+d7kYe/06R79MdjZE7AxdMEbqYMy fq3BV33wzoji4KMG2AsRVN7dQcWDygyK06LlohfyySQZ5+93vZ9Ilel1vyCkiQBeHhHxrEU9NRO c+krGxHV30McNv5af8w3I3VddgKfWOj8+8tco+uzHVH//AHD5x9wyHeCXeYd5Ik2O3qhl+wKhwL Q+n7V3f5BO13sJqBIYKjWXr3UJanxiWxxbyeGVc78g5oFmzbHDaW/p0xHjFLE7rzGcoK887ixfD yIKQ1oDBll4EI8buBNk4ltETe5taI9WpnLstwSzm0LkPZTo0NMP8Bxo1Hvs7f5PXUg== X-Google-Smtp-Source: AGHT+IEKJBeGw3BGvps64oymWel6q4HV3SvXQq1Y+4QttRACn/hU/DYbQL1qZU6myhsPGeEgI6x6Kw== X-Received: by 2002:a05:6402:40c9:b0:5d1:1064:326a with SMTP id 4fb4d7f45d1cf-5d81ddbf672mr89182571a12.15.1735654505653; Tue, 31 Dec 2024 06:15:05 -0800 (PST) Original-Received: from pro2 (p200300e0b7216c0021e5e367c6afc189.dip0.t-ipconnect.de. [2003:e0:b721:6c00:21e5:e367:c6af:c189]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aaf5d43429bsm249826266b.154.2024.12.31.06.15.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 31 Dec 2024 06:15:05 -0800 (PST) In-Reply-To: <86msgcm1nm.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 31 Dec 2024 15:18:21 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::52f; envelope-from=gerd.moellmann@gmail.com; helo=mail-ed1-x52f.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:327506 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: Eli Zaretskii , pipcet@protonmail.com, >> spd@toadstyle.org, emacs-devel@gnu.org >> Date: Tue, 31 Dec 2024 10:19:15 +0100 >>=20 >> Helmut Eller writes: >>=20 >> > Except the POSIX police: it says that pthread_mutex_trylock isn't async >> > signal safe. I suppose this also makes it's unsafe to use MPS's fault >> > handler in an async signal handler. Bummer. (Does the police take >> > bribes?) >>=20 >> Thanks. I guess it shows that I couldn't keep up with my mail, sorry for >> that. >>=20 >> So we have this picture, I think >>=20 >> t1 t2 t3 >> ------------|------------|---------------------|-----------------> t >> signal pthread other stuff signal handler >> handler trylock until return to branching >> calling signal handler on result of busy >> mps_arena_ >> busy >>=20 >> We have a window [t1, t2] where the nested signals lead to undefined >> behavior. and [t2, t3] where threads and nested signals can come into >> play, but that's not a problem, iff signal handlers don't leave a lock >> behind them. > > If the problem is other signals in [t1, t2], we could install the > signal handler in a way that masks all other signals while the handler > runs. That would be necessary, but there's another thing Helmut pointed out. At t0, when we enter the SIGPROF handler, we may have interrupted pthread code in the Emacs thread, so pthread may currently be in an inconsistent state. I'd like to instead revive the idea of getting the backtrace in the signal handler and doing anything else elsewhere. What I've seen so far as alternatives is for my taste in the end too difficult. We have established that calling get_backtrace is safe since it doesn't access memory in our AMC pool, which might have a barrier. Counter argument was that one would have to know too much about what is safe to access and what cannot, and that would be unmaintainable. What one has to know in get_backtrace is - struct thread_state is safe because it is Lisp object. but it is not in the AMC pool, but another pool not using barriers. One could "hide" that knowledge by putting get_backtrace into igc.c. We only need the binding stack members (specpdl*) from current_thread. Another function. =20=20 - Accessing any other Lisp objects is taboo. That includes any memory of the object, in particular it includes their headers, i.e. type checks for PVEC types. One could require no type checks. =20=20 - Copying Lisp_Object and such is okay because that does not access the memory of the referenced object. Maybe, after reading igc.org, that is acceptable maintenance-wise?