From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: pipcet@protonmail.com, ofv@wanadoo.es, emacs-devel@gnu.org,
eller.helmut@gmail.com, acorallo@gnu.org
Subject: SIGPROF + SIGCHLD and igc
Date: Tue, 24 Dec 2024 07:03:53 +0100 [thread overview]
Message-ID: <m2o711ehx2.fsf_-_@gmail.com> (raw)
In-Reply-To: <m27c7qf7lt.fsf@gmail.com> ("Gerd Möllmann"'s message of "Mon, 23 Dec 2024 21:49:02 +0100")
(I've given this a new subject.)
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, ofv@wanadoo.es, emacs-devel@gnu.org,
>>> eller.helmut@gmail.com, acorallo@gnu.org
>>> Date: Mon, 23 Dec 2024 18:44:42 +0100
>>>
>>> BTW, do you know which signal handlers use Lisp, i.e. allocate Lisp
>>> objects or access some? All? Or, would it be realistic to rewrite signal
>>> handlers to not do that?
>>
>> SIGPROF does (it's the basis for our Lisp profiler).
>>
>> SIGCHLD doesn't run Lisp (I think), but it examines objects and data
>> structures of the Lisp machine (those related to child processes).
>>
>>> One thing I've seen done elsewhere is to publish a message to a message
>>> board so that it can be handled outside of the signal handler. Something
>>> like that, you know what I mean.
>>
>> This is tricky for the profiler, because you want to sample the
>> function in which you are right there and then, not some time later.
>>
>> For SIGCHLD this could work, but it might make Emacs slower in
>> handling subprocesses (there are some Lisp packages that fire
>> subprocesses at very high rate).
>
> Thanks.
>
> I've looked at SIGPROF. From an admittedly brief look at this, I'd
> summarize my results as:
>
> - The important part is get_backtrace. The rest could be done elsewhere
> by posting that to a message board, or whatever the mechanism is at
> the end.
>
> - Didn't see get_backtrace or functions called from it allocating Lisp
> objects.
>
> - It reads from a Lisp object because of
>
> #define specpdl (current_thread->m_specpdl)
> #define specpdl_end (current_thread->m_specpdl_end)
> #define specpdl_ptr (current_thread->m_specpdl_ptr)
>
> current_thread is a struct thread_state which is a PVEC_THREAD.
>
> - I remember that I wrote a scanner for the specpdl stacks, so that's
> not a Lisp object but a root, so no problem here, I think.
>
> - struct thread_state allocation is done in igc.c via alloc_immovable in
> igc_alloc_pseudovector. That allocated from from an AMS pool, which
> doesn't use barriers.
>
> - It doesn't seem to access other Lisp objects except current_thread.
>
> That doesn't look bad, I think. Worth mentioning is perhaps that
> directly after get_backtrace here
>
> static void
> record_backtrace (struct profiler_log *plog, EMACS_INT count)
> {
> log_t *log = plog->log;
> get_backtrace (log->trace, log->depth);
> EMACS_UINT hash = trace_hash (log->trace, log->depth);
>
> we access Lisp objects in trace_hash when computing the hash and in the
> other hash table code. IIUC that code counts hits with the same
> backtrace. Don't know how long that takes. But if posting the backtrace
> would take the same time, we would be on par.
>
> I'll try to also look at SIGCHLD at some later point, but Christmas,
> family etc.
>
> Happy holidays!
Been up a bit early, so...
This is about SIGCHLD, and I must say I find it a bit hard to tell if
all other platforms do the same. There are simply too many #if's to
consider in the signal handling code.
Anyway, what I see here: SIGCHLD doesn't do anything dangerous in the
signal handler. Instead, the occurrence of SIGCHLD is added to a queue
with enqueue_async_work and that's basically it.
The work items in the queue are processed by process_pending_signals,
outside of the signal handler. Very nice, that's how it should be :-).
(And maybe, just as an inspiration, one could use that construct for
SIGPROF?)
So, there is actually no problem at all with SIGCHLD that I can see.
My personal summary for SIGPROF + SIGCHLD at this point:
- I recommend rewriting SIGPROF handling in the way I tried to describe,
possibly using the existing work queue mechanism. Everything else looks
too complicated to me.
- Lisp allocation in signal handlers cannot exist because alloc.c is not
reentrant which means we would crash with the old GC. We don't need
anything extra for that in igc.
- No longer wondering why macOS does not show any problems in that whole
area. The only problem is SIGPROF accessing Lisp objects, and the
memory barrier is not a problem on macOS because it doesn't use
signals.
Please double-check!
next prev parent reply other threads:[~2024-12-24 6:03 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-22 15:40 Some experience with the igc branch Óscar Fuentes
2024-12-22 17:18 ` Gerd Möllmann
2024-12-22 17:29 ` Gerd Möllmann
2024-12-22 17:41 ` Pip Cet via Emacs development discussions.
2024-12-22 17:56 ` Gerd Möllmann
2024-12-22 19:11 ` Óscar Fuentes
2024-12-23 0:05 ` Pip Cet via Emacs development discussions.
2024-12-23 1:00 ` Óscar Fuentes
2024-12-23 3:42 ` Gerd Möllmann
2024-12-23 6:27 ` Jean Louis
2024-12-22 20:29 ` Helmut Eller
2024-12-22 20:50 ` Gerd Möllmann
2024-12-22 22:26 ` Pip Cet via Emacs development discussions.
2024-12-23 3:23 ` Gerd Möllmann
[not found] ` <m234ieddeu.fsf_-_@gmail.com>
[not found] ` <87ttaueqp9.fsf@protonmail.com>
[not found] ` <m2frme921u.fsf@gmail.com>
[not found] ` <87ldw6ejkv.fsf@protonmail.com>
[not found] ` <m2bjx2h8dh.fsf@gmail.com>
2024-12-23 14:45 ` Make Signal handling patch platform-dependent? Pip Cet via Emacs development discussions.
2024-12-23 14:54 ` Gerd Möllmann
2024-12-23 15:11 ` Eli Zaretskii
2024-12-23 13:35 ` Some experience with the igc branch Eli Zaretskii
2024-12-23 14:03 ` Discussion with MPS people Gerd Möllmann
2024-12-23 14:04 ` Gerd Möllmann
2024-12-23 15:07 ` Some experience with the igc branch Pip Cet via Emacs development discussions.
2024-12-23 15:26 ` Gerd Möllmann
2024-12-23 16:03 ` Pip Cet via Emacs development discussions.
2024-12-23 16:44 ` Eli Zaretskii
2024-12-23 17:16 ` Pip Cet via Emacs development discussions.
2024-12-23 18:35 ` Eli Zaretskii
2024-12-23 18:48 ` Gerd Möllmann
2024-12-23 19:25 ` Eli Zaretskii
2024-12-23 20:30 ` Benjamin Riefenstahl
2024-12-23 23:39 ` Pip Cet via Emacs development discussions.
2024-12-24 12:14 ` Eli Zaretskii
2024-12-24 13:18 ` Pip Cet via Emacs development discussions.
2024-12-24 13:42 ` Benjamin Riefenstahl
2024-12-24 3:37 ` Eli Zaretskii
2024-12-24 8:48 ` Benjamin Riefenstahl
2024-12-24 13:52 ` Eli Zaretskii
2024-12-24 13:54 ` Benjamin Riefenstahl
2024-12-23 17:44 ` Gerd Möllmann
2024-12-23 19:00 ` Eli Zaretskii
2024-12-23 19:37 ` Eli Zaretskii
2024-12-23 20:49 ` Gerd Möllmann
2024-12-23 21:43 ` Helmut Eller
2024-12-23 21:49 ` Pip Cet via Emacs development discussions.
2024-12-23 21:58 ` Helmut Eller
2024-12-23 23:20 ` Pip Cet via Emacs development discussions.
2024-12-24 5:38 ` Helmut Eller
2024-12-24 6:27 ` Gerd Möllmann
2024-12-24 10:09 ` Pip Cet via Emacs development discussions.
2024-12-24 4:05 ` Gerd Möllmann
2024-12-24 8:50 ` Gerd Möllmann
2024-12-24 6:03 ` Gerd Möllmann [this message]
2024-12-24 8:23 ` SIGPROF + SIGCHLD and igc Helmut Eller
2024-12-24 8:39 ` Gerd Möllmann
2024-12-24 13:05 ` Eli Zaretskii
2024-12-24 12:54 ` Eli Zaretskii
2024-12-24 12:59 ` Gerd Möllmann
2024-12-23 23:37 ` Some experience with the igc branch Pip Cet via Emacs development discussions.
2024-12-24 4:03 ` Gerd Möllmann
2024-12-24 10:25 ` Pip Cet via Emacs development discussions.
2024-12-24 10:50 ` Gerd Möllmann
2024-12-24 13:15 ` Eli Zaretskii
2024-12-24 12:26 ` Eli Zaretskii
2024-12-24 12:56 ` Gerd Möllmann
2024-12-24 13:19 ` Pip Cet via Emacs development discussions.
2024-12-24 13:38 ` Gerd Möllmann
2024-12-24 13:46 ` Eli Zaretskii
2024-12-24 14:12 ` Gerd Möllmann
2024-12-24 14:40 ` Eli Zaretskii
2024-12-24 12:11 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2o711ehx2.fsf_-_@gmail.com \
--to=gerd.moellmann@gmail.com \
--cc=acorallo@gnu.org \
--cc=eliz@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=ofv@wanadoo.es \
--cc=pipcet@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).