all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Gerd Möllmann" <gerd.moellmann@gmail.com>
To: Pip Cet <pipcet@protonmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
	 ofv@wanadoo.es,  emacs-devel@gnu.org, eller.helmut@gmail.com,
	 acorallo@gnu.org
Subject: Re: Some experience with the igc branch
Date: Tue, 24 Dec 2024 05:03:36 +0100	[thread overview]
Message-ID: <m2zfklenhj.fsf@gmail.com> (raw)
In-Reply-To: <87ldw6as5f.fsf@protonmail.com> (Pip Cet's message of "Mon, 23 Dec 2024 23:37:13 +0000")

Pip Cet <pipcet@protonmail.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?
>
> I think there are several questions hiding behind the first question
> mark:
>
> 1. which signal handlers want to read Lisp data
> 2. which signal handlers want to write Lisp data
> 3. which signal handlers want to allocate Lisp objects temporarily,
> while guaranteeing no references to those objects survive when the
> signal handler returns.
> 4. which signal handlers want to allocate Lisp objects permanently,
> storing references to the new objects in "old" data
> 4a. ... and are willing to call a special transformation function to do
> so
> 4b. ... and want to do so implicitly, expecting memory manipulation to
> "just work".

New day, new beliefs :-). Today, when I read my question again, I'd
actually be surprised if a signal handler could allocate Lisp objects
because I wouldn't be able to explain how that works with alloc.c which
isn't reentrant. Not even Fcons is reentrant when I look at it now.

Correct, or am I overlooking something? Could others please check? If
it's right, things get a lot easier.

Maybe allocation of Lisp objects on the stack remains as some sort of
problem (AUTO_CONS etc)? I don't see how though, ATM.

> 1: definitely works
> 2: should work, but may hit a write barrier
> 3: could be made to work if there's interest
> 4a: if we must
> 4b: see the other thread.  If we have both make_object_writable
> (formerly CHECK_IMPURE) and commit_object_changes functions and call
> them consistently, it might be possible to find a way.
>
>> SIGPROF does (it's the basis for our Lisp profiler).
>
> That's 1, 2, but not 3 or 4, right?
>
>> SIGCHLD doesn't run Lisp (I think), but it examines objects and data
>> structures of the Lisp machine (those related to child processes).
>
> Just 1, then?
>
>>> 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.
>
> But would it be so bad to use a copy of the specpdl stack, placed in a
> prepared area which is a GC root so we'd guarantee survival (but not
> immutability; I don't think that matters in practice) of entries?
> memcpy is safe to call from a signal handler, and then we could do all
> of the processing safely.
>
> (My preference would be to make the specpdl stack an ambiguous root
> while the profiler is in use: that way, we'd get usable backtraces even
> if the SIGPROF happened during GC, which is probably more useful than
> merely saying that we were in GC).
>
> Pip

I'd prefer to send messages from handle_profiler_signal. Or something
equivalent to sending messages. Please see my other mail where I looked
at that function. Implementing such a message board is of course not
easy. But I think it would be easy to understand how things work once one
has something like that.

And if I'm right with what I wrote above about allocation (and I think I
am), we also don't need provisions for allocating Lisp objects from
signal handlers, which would be a great simplification.




  reply	other threads:[~2024-12-24  4: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                     ` SIGPROF + SIGCHLD and igc Gerd Möllmann
2024-12-24  8:23                       ` 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 [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2zfklenhj.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.