From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MPS: User GC customizations Date: Thu, 04 Jul 2024 21:39:33 +0300 Message-ID: <861q4980ii.fsf@gnu.org> References: <87v81pbgzi.fsf@localhost> <87y16khvhy.fsf@localhost> <87frspqwhr.fsf@localhost> <87tth5pdqc.fsf@localhost> <87le2h47kj.fsf@localhost> <86a5ix82nt.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37104"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org, eller.helmut@gmail.com To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 04 20:40:31 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 1sPRNe-0009PZ-Sp for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Jul 2024 20:40:30 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sPRN3-0007Ov-IU; Thu, 04 Jul 2024 14:39:53 -0400 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 1sPRN2-0007OO-57 for emacs-devel@gnu.org; Thu, 04 Jul 2024 14:39:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sPRN1-0006ma-Om; Thu, 04 Jul 2024 14:39:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=CIgkBgLEZ5JlrsDj8hqvBBCWMqe6tCHrnHQ4gS82QM4=; b=T7iZTJBxkNXsdSnEoSl4 nSXEAhDnynkxeMkRJFJrXSVxt69gbJScRQZNUPGT6efM3l42SIx9mJ6Z7Wwkl2KxT77IxtK6fZhHz LRX+jQgRh0yuoj2KfSrMb/CxFgoLR19DaZ/mbla7cLN9rlp8kEytIFu8RXfIHM5zMlmSe0CERWo+G GQA+TQDxPsejOX+/cUX/WbUcl+9W8C4DM2rQCkfxgUtsdeZE/3nFkrOQGS+IyfaxlVSPTY0MdEre0 l9/nFpDav8+IPg2wsWo3lwfWZGlP7vq/RZJXvYW5Tj+J71p2g9XPkPlSN/VWWzH7MvE1SwE5/0Tyw bEevl3ltwO3aVg==; In-Reply-To: (message from Gerd =?utf-8?Q?M=C3=B6llmann?= on Thu, 04 Jul 2024 20:18:31 +0200) 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:321352 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, yantar92@posteo.net, emacs-devel@gnu.org, > eller.helmut@gmail.com > Date: Thu, 04 Jul 2024 20:18:31 +0200 > > Eli Zaretskii writes: > > >> From: Gerd Möllmann > >> Cc: Ihor Radchenko , Eli Zaretskii , > >> emacs-devel@gnu.org, eller.helmut@gmail.com > >> Date: Thu, 04 Jul 2024 18:07:42 +0200 > >> > >> Pip Cet writes: > >> > >> > I think we can just set flags for "called MPS" and "in a scan > >> > function" and look at them in the SIGPROF handler to distinguish the > >> > four cases? > >> > >> Not sure. What if MPS calls these in its own thread? I guess that > >> wouldn't be so interesting for Ihor. > > > > AFAIU, on GNU/Linux signals are delivered to the main thread, > > Pip mentioned scan functions, so let's say we set a flag in_scan while > being in dflt_scan. MPS now calls dflt_scan, in the MPS thread, to do an > increment of its work. While in dflt_scan we get SIGPROF and land in the > signal handler in main thread, and the profiler sees in_scan == true. > > Q: do we count that as part of GC work that the profiler should report, > although it happened in the MPS thread? I understood Ihor as saying that > he doesn't want that. We probably don't want that, no. So in_scan should not be a boolean, it should probably hold the thread ID of the thread which set the flag. Anyway, we are putting the wagon before the horse. These subtle issues of how to account for GC in a profile are very far from the fundamental problems we have to solve at this stage. We didn't yet agree on the final design of handling SIGPROF (and other useful signals), so talking about these aspects is simply a waste of time. Ihor, please record the issue and raise it much later, when we have the basics figured out. It is not useful to raise this now.