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: Fri, 27 Dec 2024 15:53:43 +0100 Message-ID: <87wmfl6utk.fsf@gmail.com> References: <87o713wwsi.fsf@telefonica.net> <87ldw7fwet.fsf@protonmail.com> <87a5cnfj8t.fsf@protonmail.com> <86seqe4j4f.fsf@gnu.org> <87ttaucub8.fsf@protonmail.com> <87pllicrpi.fsf@protonmail.com> <864j2u442i.fsf@gnu.org> <87a5ch5z1b.fsf@gmail.com> <86y101wlsr.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="35461"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: gerd.moellmann@gmail.com, pipcet@protonmail.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 Fri Dec 27 15:54:43 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 1tRBjf-00099M-4O for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Dec 2024 15:54:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRBip-0001rh-HF; Fri, 27 Dec 2024 09:53:51 -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 1tRBin-0001rH-Pl for emacs-devel@gnu.org; Fri, 27 Dec 2024 09:53:49 -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 1tRBim-0006iA-3T; Fri, 27 Dec 2024 09:53:49 -0500 Original-Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5d3e8f64d5dso12639452a12.3; Fri, 27 Dec 2024 06:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735311225; x=1735916025; 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=r8ZObsWtPuzstWfXDDg2ZNu3bCR4rpVLrX6R+oYPxVI=; b=OmbDGOehXgWV10uQ8/RHni8l9dWrfN1ZMMSKZcA7FmsGmSI28b/oQp8UmwKOxw8Hx9 e/bYP7c0O3SyE4owS1We3JTcTmHyywoZoqBBeDP3UBXvnSGQC0ERaIoBjOVjZhVMqRhR qKL76bsBRiJ2Lhqp+PWNvDml4aH6+VTvDIA6Nv67Lpmus6xXm3Rr4nJlViRwW0DMm7p0 thKAUPPAleKszdiIWh90VIXV9MgxfjZ8yQCYUfbTNALICiX9M8P9cLFpepxvyO0OU0uz 6shuczVAJ1/xfgYmRPNbXJtHZTFBbQ1tg/Fbc0iJcAbROh6UGeEZjObdBxMijgk4gtvX BRxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735311225; x=1735916025; 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=r8ZObsWtPuzstWfXDDg2ZNu3bCR4rpVLrX6R+oYPxVI=; b=B+cn5sFjez1OczYN0+NW0oRDqpOPnYQVx/YOTBVgnB949qId+LNqiy8oSZeQOKl1a+ 7dmsI5s2e2RTAZuJL8nxesh5/Mv2s+e6eey8iOSTBnrEYggTgm1usql9czPLSavV7NY4 sPkuQ/BNBUoV3QtOVu6tJXGnIP+MkUYaMJGoCf7/mlOlJkkquFd2hCTPrV9+xbxJO5BU uAfO8XjYIuHQxevaOJjJToiNocn2yc4iXXi9k9VqhobHfyVCSycf6loKQhBGHPJN97/D 9eBo2IDJgkT0K1bsIRU1OPabcPrSnYHeC010fb4x6UiYpC0fSyrY7fP4m5EYHsEoXVrQ GwhQ== X-Forwarded-Encrypted: i=1; AJvYcCU7wLJqAC5SoaMohgvoL4WcSmquPvNjSXu6zboUCQo5ZRAkRZ/I5uzUYToscfP7dDbvDnM+6bIFrQ==@gnu.org, AJvYcCXD4VpyuTRRPnjfNpllwH5DlaCtNlptY3UBE9Lx+pPAavUxxZZorgFDoM4iHKaZEY3m5HdmiIO5K+suk6Y=@gnu.org X-Gm-Message-State: AOJu0YyC5l2pqln6Kj0ieLrL5P2aN6cjDGdE6bgB6kpfu5HuG4bE/0le g0aB6Fk/CyX50p7OxFwBXr5a1muudprYy7/TP1Y+kq3NRODvlzw0JSaZ0qx5 X-Gm-Gg: ASbGncsR+IBWxGXfrAAivYx0bBS69bpr69huSRTVSGZ7Jb7KMhImHqjiwImnto1UY17 B9GhQ4C1h3UGyP4fJzmzk1Xlnw3MOXv3IsCjOjTFOhHifaYz+Nwe7yQTL+pMdLTWtoxmq+EkzNH poIRQvl49eRbmidJ31BXwLNJk5QSciF0bn9kWd8ROuZHIWnefXzmtcYzZ1Z/J4GGqfJPpT741Tx a2tXbWhn6gnI3OcM/o7JQamT/ERm4/jkqPrevQCLcEvuu1Yufg2Bdo= X-Google-Smtp-Source: AGHT+IEsk5fdLUnUmfggvX6rpmq2d0gcK9AoyuZn36n4ClehtxY4lCp7GE1bNSN0PD45Pdmxkb9yDA== X-Received: by 2002:a05:6402:540a:b0:5d1:f009:9266 with SMTP id 4fb4d7f45d1cf-5d81ddd6d22mr25130540a12.2.1735311225154; Fri, 27 Dec 2024 06:53:45 -0800 (PST) Original-Received: from caladan ([31.177.115.143]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-5d807616bc1sm11197183a12.29.2024.12.27.06.53.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Dec 2024 06:53:44 -0800 (PST) In-Reply-To: <86y101wlsr.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Dec 2024 10:51:48 +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:327196 Archived-At: On Fri, Dec 27 2024, Eli Zaretskii wrote: >> I have an idea how to make a safer profiler. First, remember that MPS >> will stop mutator threads to protect its own consistency. > > Can you spell out what are "mutator threads" in this context, so we > all are on the same page? The mutator threads are those that we register with mps_thread_reg. >> What happens if we make the profiler its own thread? MPS will stop >> the profiler like normal mutator threads. This is useful and is as >> it should be. > > AFAIU, it means the profiler will not be able to account for GC, but > let's put this aside for a moment. Yes. Probably a similar issue as when SIGPROF is blocked while threads are stopped. >> The problem now is how the profiler thread can do what get_backtrace >> does. We can use a protocol between the profiler thread and the main >> thread that goes like this: >> >> 1. The profiler periodically sends a signal, say SIGPROF, to the main >> thread. >> >> 2. In the signal handler for SIGPROF, the main thread synchronizes >> itself with the profiler by communicating over a pipe (like the Unix >> fathers did it). It sends some token to the profiler and waits. >> >> 3. The profiler receives the token and can now access the virtual >> machine state because the main thread waits. The profiler now does >> what get_backtrace does. After logging the stack snapshot, the >> profiler sends the token back to the main thread >> >> 4. The main thread receives the token, returns from the signal handler, >> and continues execution. > > You are basically describing the way SIGPROF emulation is implemented > on Windows (see w32proc.c for the details). Good; then I assume that we don't need to discuss that this might introduce too much overhead. > But I don't understand > why you need that pipe: doesn't pthreads allow one thread to stop the > other? If so, just make the "profiler thread" stop the main thread > instead of your step 2, and resume the main thread instead of your > step 4. Am I missing something? You mean there is a phtread_stop function that is similar to SuspendThread on Windows? I've not found anything like that; but that doesn't mean that there isn't one. The Linux man-pages for pthreads are notoriously useless. I like the pipe because it's a signal safe and thread safe communication mechanism. It avoids the need for mutexes or stdatomic stuff; that's best left to wizards. >> Note that the signal handler only communicates over the pipe and doesn't >> read or write any memory that could mess up MPS. The profiler thread >> doesn't run any signal handlers (other than those that MPS may use >> behind the scenes). > > You basically emulate blocking of SIGPROF by relying on MPS to stop > the profiler thread when it cannot allow access to memory that could > mess up MPS, is that right? Exactly. >> Another observation: MPS sends SIGXFSZ and SIGXCPU to stop and resume >> threads. We could intercept those signals and block SIGPROF while the >> thread is stopped. Obviously a hack, but could still be useful. > > Do these signals get delivered to the main thread as well? Or only to > mutator threads? I've not looked too closely, but the documentation for ThreadRingSuspend suggests that they are delivered to all threads, except for the current thread. So if a non-main thread triggers a GC cycle, then the main thread would receive them too. Helmut