Re: MPS: User GC customizations

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> 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 <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: Ihor Radchenko <yantar92@posteo.net>,  Eli Zaretskii <eliz@gnu.org>,
> >>   emacs-devel@gnu.org,  eller.helmut@gmail.com
> >> Date: Thu, 04 Jul 2024 18:07:42 +0200
> >> 
> >> Pip Cet <pipcet@protonmail.com> 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.