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: Mon, 30 Dec 2024 16:30:44 +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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39077"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Pip Cet , Eli Zaretskii , spd@toadstyle.org, emacs-devel@gnu.org To: Helmut Eller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 30 16:31:36 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 1tSHjz-000A4G-U9 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Dec 2024 16:31:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSHjK-0007Lq-Nt; Mon, 30 Dec 2024 10:30:54 -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 1tSHjI-0007LD-Uv for emacs-devel@gnu.org; Mon, 30 Dec 2024 10:30:53 -0500 Original-Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tSHjE-0002Pm-Jy; Mon, 30 Dec 2024 10:30:52 -0500 Original-Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-aa679ad4265so1860335466b.0; Mon, 30 Dec 2024 07:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735572646; x=1736177446; darn=gnu.org; h=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=uzq+YwJKge+S5WS82nJPOwovNNY1Tf+LuydJawPecEQ=; b=aQJJa+MzCPUkhmyJ8aPjvB0F0gXNEA7X0R0Oe3nIb+58bEMfHhT4TIAlFD+uV0NAhm A6CvkSl+OMtiEryld24kQNPSx7H40uEDP+oZnN+Jr2y06nGiOEnJN82zh6ffuoj4iguu 7fCXmtvids7VGZDDgstlssspKMYzwGzcPsCh6aGxEbc/pRwb0XRJGoMl0PqWt2SLDFW1 DPnghNMS0smCZZM/V0SJ7WKd8Yw5UTRzNNzUGg2XvZzDThdaOR2Pz6bgn3HJ5QlPxb7+ iD8vLfDReQlaMzK9/xV5WOMSZ/3e2L1prfmY6PCkzlv+IX1LmI85iZKLaIR+6NY+8we3 XIgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735572646; x=1736177446; h=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=uzq+YwJKge+S5WS82nJPOwovNNY1Tf+LuydJawPecEQ=; b=NQ/DpbQrxksrT6J7dhaseRWdNQkIaVnAK9z8a2ucfiuFja4akDg0GiLj4wFjOj1ZeN vDbqjpxJxoOMDZRnyBnYGNVjUwp2FhzMGbEacg0eidZFuoNsm024iBAH6tF6SnV7Y2af Ex8bmCp+vb57LhAtH8E7pTET+LqtYha+hY4P5pHWbjFhBFXiupBg3B7jDpzoy1zF4G7f QpgkqZgyGLgUU1tMvME+GztlsQxO93RGf8W6mT3CZ/6RQgW1LgfY+3gJfTN2r9rGXolw dHK3o9hI1LvCJuy7wJN3/YZz/oULSgD7qbKy4hDAbwLEyHxsD1bSDl2eoqjtmaDwyRlK Axyg== X-Forwarded-Encrypted: i=1; AJvYcCU1hhErAletlKDdipqvicnrjF5Sp1BL9gP/Rev4usNASgKZ6xy6kJZe1ZZJ5IMMJeMRif85@gnu.org, AJvYcCXKEzsjD0kw22OkdCfq8gApfC13KsRHpblyPWHaUYyXIOsFS2Fk/o2S9un3Fh35b/9aN8WaC/bQU+VKIBw=@gnu.org X-Gm-Message-State: AOJu0Yxf8goYl1RuY+9i5bklPZiCfpKEiSIGqniaUxAmKuyFSV9Z63Gd 6XYUeNWSyeg4ncylLtwVDomhoYFFRpZMIsadEPA1OdbI4N5HUvxotIGrkA== X-Gm-Gg: ASbGncs3EohvcUH5TWGnkcnm3roxT0pp2qyJoABarCr9yOL2EpNGesnhfzj0IAAFxlv mV4Sy4UipfxLrUmAazfrfAn0/s6JbytN/cvTHm26a03uuPrStxHARaFNHOz3yJ1jTfmfWIO+f1h hu6InZR+sAOT1TsMvUkcaaKU6Yu13+MOuRQlzcwrWcaiuuoZ2Nimcxy9c9zB4q2T+JCjm50JSIz uNwTRKlQGAYi+sx0sc7BRfpd4q3eugNLUe+SR1VHFYyDW4Q5UYJ3YipRRs6BER6F4SbLCs9stPK LDKms8Jp8NP8M0pKANyG6S4oguqyxSs2DyTyZ8+MUKYkMhzRqoYXbtcnW9QXH0XX X-Google-Smtp-Source: AGHT+IEDbzfhXlFaRRbcCJszKxag5+8z8iWezInojYE5CycugjWVZVkTS3NT2W30h8rlBZ2G/uyJfA== X-Received: by 2002:a17:907:6e88:b0:aa6:9540:5714 with SMTP id a640c23a62f3a-aac0826ec8fmr3400299466b.25.1735572645737; Mon, 30 Dec 2024 07:30:45 -0800 (PST) Original-Received: from pro2 (p200300e0b7156f000dceccb84ca1ba38.dip0.t-ipconnect.de. [2003:e0:b715:6f00:dce:ccb8:4ca1:ba38]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0e89617bsm1463333766b.76.2024.12.30.07.30.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Dec 2024 07:30:45 -0800 (PST) In-Reply-To: <874j2lmd37.fsf@gmail.com> (Helmut Eller's message of "Mon, 30 Dec 2024 15:59:08 +0100") Received-SPF: pass client-ip=2a00:1450:4864:20::632; envelope-from=gerd.moellmann@gmail.com; helo=mail-ej1-x632.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:327443 Archived-At: Helmut Eller writes: > On Mon, Dec 30 2024, Pip Cet wrote: > >> "Helmut Eller" writes: >>> Very few of Emacs' signal handlers actually touch a barrier. I've also >> >> Indeed. These crashes are rare in typical usage, which doesn't mean we >> should delay fixing them until Emacs is "unstable enough". It already >> is, IMHO, because we take that approach too frequently. >> >>> not seen any reproducable receipes for the "signal issues" that the igc >>> branch supposedly has. >> >> Removing the SIGPROF protection code should allow Ihor's recipe to crash >> again. > > Talking about SIGPROF protection code. It appears to me now (again) > that, for the SIGPROF handler, this pseudo code > > if (mps_arena_busy ()) > plog->gc_count = saturated_add (plog->gc_count, count); > else > record_backtrace (plog, count); > > is safe. If we don't hold the lock, then mps_arena_busy returns false > and we can access memory. We are safe even if another thread has > claimed the lock by the time that we reach record_backtrace: the SIGPROF > handler will just block until the lock is released. > > Does somebody disagree? > > Helmut That's this: mps_bool_t mps_arena_busy(mps_arena_t arena) { /* Don't call ArenaEnter -- the purpose of this function is to * determine if the arena lock is held */ AVER(TESTT(Arena, arena)); return ArenaBusy(arena); } Bool ArenaBusy(Arena arena) { return LockIsHeld(ArenaGlobals(arena)->lock); } Bool (LockIsHeld)(Lock lock) { AVERT(Lock, lock); if (pthread_mutex_trylock(&lock->mut) == 0) { Bool claimed = lock->claims > 0; int res = pthread_mutex_unlock(&lock->mut); AVER(res == 0); return claimed; } return TRUE; } There might be a small window after pthread_mutex_trylock and being back in the signal handler. Can anything happen in this window? If no other Emacs threads are running, and the Emacs thread is in the signal handler, we can trust the "false" from the mps_arena_busy. If other threads were running (and I don't think that's currently the case), the "false" also means that the Emacs thread in the signal handler can't have the lock. In the "true" case from mps_arena_busy, we're anyway not doing much. So I think I agree.