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: SIGPROF + SIGCHLD and igc Date: Sat, 28 Dec 2024 14:52:33 +0100 Message-ID: <877c7jlxsu.fsf@gmail.com> References: <87o713wwsi.fsf@telefonica.net> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87a5ch5z1b.fsf@gmail.com> <87plld5pev.fsf@protonmail.com> <87ed1t6r34.fsf@gmail.com> <875xn46s6z.fsf@gmail.com> <86bjwwulnc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24073"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: pipcet@protonmail.com, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 28 14:53:30 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 1tRXFx-0006Bx-Vz for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Dec 2024 14:53:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRXFA-0008VM-M1; Sat, 28 Dec 2024 08:52:40 -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 1tRXF9-0008VD-3K for emacs-devel@gnu.org; Sat, 28 Dec 2024 08:52:39 -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 1tRXF7-0006LW-Kl; Sat, 28 Dec 2024 08:52:38 -0500 Original-Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5d0d32cd31aso11224761a12.0; Sat, 28 Dec 2024 05:52:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735393955; x=1735998755; 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=qBXEOfTttDoMNtxz96yqOqb8dwAfQ2A8gt8YoZ5cdBU=; b=K4pt/E98Q4i31laF2+e42iu3bEfRvhXONVmCP+551eKAYENqeP67LRDo3dlV77p4p9 MQPaE3xX1oV466zwIBGcMRyt/baO9PkDxnGoY9yEujciARgd3r2zxcaxW1BYsFqYUQ74 i0m+++jCmWCCYeFFChE6Y6VFNBPqRB3UaWI1Qdc6X1tYE20WIIgZf2ybyPyhPGoLnJOs ZlsNWB6pAjjq8K6gs0SWpK2BlRE+7hhgtZepxUs5e3yoJYBQ0+Uw2u/7Z6bWN4qNAGLF q5+NExfbYEpxJLE2yVgkVw32OPyrIg1zcBNAmzl7fibOLE0uap1cl97s/ocAf8EzWCw9 snwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735393955; x=1735998755; 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=qBXEOfTttDoMNtxz96yqOqb8dwAfQ2A8gt8YoZ5cdBU=; b=pLudqwth6u9FwimNqABaGOLNB6OqhOLtq+KxtPnTr/Q5UiuYsh8m5+2imfY2RRQQif okR/NGWPp3XS0Y+6/JZ7Lz22Bh8OeI1IMEN9g5BY0bLj8g/Yt4oKy11e9iIs1GJVvOR5 PeEUbHvdouNIbGEQ4d6llAOfuMiZ4+Ego6Yafg0e//v6KSomSpnhdzfvA9i/iuNyBYB8 tjfoV7sc3eLWbiXkdmwMpUXPjGO/AUKQ/I1H2P8zUAwQXhSPVrp6kiAbnwCqOZvvnlON GHNOQcwIuVSLhF2Tahw1jCT02Nq8BYrssH+Pt2sYtWdGTlCzzLQ4jNMwZTqa+IJ40dmY sHiA== X-Forwarded-Encrypted: i=1; AJvYcCVAdZzj+2PW8QYkb9ECxq4g30JteMvN9tALC6pzCt0gHO9fIsGl7+lvCkHdd0Pt8DB+VIiUUVcduKIMZrY=@gnu.org, AJvYcCWfpD97fJd7AsT7tqQLgV2JEsCuh/FkfWJxs/3ojNhbbRxAZ93vjRtCpWB5v/JzgXRjMg9aMAaguw==@gnu.org X-Gm-Message-State: AOJu0Yzw5Q4eHTCUw9kxNbFqVJwf35A6FpULm4jNEe3aDpqJurxeDZ7t BxUucwXuw241jSdo0OIiKvVBsR2aTiI/EACN26VNlRVKSxc1bP5/rkuNe8Yk X-Gm-Gg: ASbGncsKa4HTRuKYtrhvmvKJnr6hzUZIDK/1Rb8XDG/xwn/iWyI4rhysOMq68FQVZln BWhs6y/OomcPl8foqAoT9BXXqyU3o/AnzxEu9PE6WgkE9D2JtzCkCImBt6iyRNQzVJyyUKtufen rKOdxsmsOJrnuxktln8UMXCIIMI9IxQkhyw2GazVMORPv2JxDWkdN0TNnouSIYIM77v29PL1RU1 WcZy3ywgl8IjanmRpDyE3oKqDJ0pi4Metkrar8wVN+GqRNEeE1Lk2E= X-Google-Smtp-Source: AGHT+IEth6Ojm+USkSzNynriqsya7HxJz8haRiljm9QU94p943H/gqNlbC71tsRWXtdNvFvnbI1ZIQ== X-Received: by 2002:a05:6402:2790:b0:5d0:e73c:b7f0 with SMTP id 4fb4d7f45d1cf-5d81de1c241mr73732826a12.28.1735393954973; Sat, 28 Dec 2024 05:52:34 -0800 (PST) Original-Received: from caladan ([31.177.115.143]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0f06deb8sm1238356766b.190.2024.12.28.05.52.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Dec 2024 05:52:34 -0800 (PST) In-Reply-To: <86bjwwulnc.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 28 Dec 2024 12:50:15 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::52f; envelope-from=eller.helmut@gmail.com; helo=mail-ed1-x52f.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:327263 Archived-At: On Sat, Dec 28 2024, Eli Zaretskii wrote: >> It seems that the statement >> >> block SIGPROF while MPS holds the lock >> >> is logically equivalent to >> >> deliver SIGPROF only while MPS does not hold the lock. > > Not necessarily. Blocking a signals delays its delivery until the > time the signal is unblocked. By contrast, what you propose will be > unable to profile code which caused MPS to take the lock. Hmm, I think I disagree. But I'm not sure of what sequence of events you're thinking of. >> This variant might be bit easier to implement. The "while MPS does not >> hold the lock" part can be implemented by claiming the lock in the >> profiler thread like so: >> >> mps_arena_t arena = global_igc->arena; >> ArenaEnter (arena); >> ... deliver SIGPROF part goes here ... >> ArenaLeave (arena); > > What happens if, when we call ArenaEnter, MPS already holds the arena > lock? Since MPS holds the lock, it would run in a different thread. So the profiler thread blocks until MPS releases the lock. ArenaEnter uses non-recursive locks. >> The "deliver SIGPROF" part goes like this: >> >> 1. The profiler thread calls pthread_kill (SIGPROF, ) and >> then waits (on a pipe or whatever). >> >> 2. The SIGPROF handler gets called and immediately notifies the profiler >> thread (without waiting for a reply). After that, it continues as >> usual calling get_backtrace etc. >> >> 3. The profiler thread awakes and releases the lock. > > This leaves a small window between the time the SIGPROF handler writes > to the pipe and the time the profiler thread calls ArenaLeave. During > that window, the arena is locked, AFAIU, and we can still have > recursive-lock situations, which cause an abort. Am I missing > something? During that time window, the lock is held by the profiler thread. The SIGPROF handler runs in the main thread. If the main thread tries to claim the lock, it will block until the profiler thread releases it. >> Regarding deadlocks: the profiler thread holds the lock while it waits. >> So MPS should not be able to stop the profiler thread there. > > Which means we don't register the profiler thread with MPS, right? I'm not sure. It may not be safe to call ArenaEnter in non-registered threads. Helmut