scratch/igc: Avoid MPS being interrupted by signals

scratch/igc: Avoid MPS being interrupted by signals

[Gerd Möllmann]

As I mentioned, I reverted

  ceec5ace134 * Avoid MPS being interrupted by signals

in my fork because I observed worse "smoothness" in interactive use on
macOS. Is this commit still strictly necessary on non-macOS now that
Helmut's changes for SIGPROF are in? If not, I'd like to reverse it on
scratch/igc.

Re: scratch/igc: Avoid MPS being interrupted by signals

[Pip Cet via Emacs development discussions.]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> As I mentioned, I reverted
>
>   ceec5ace134 * Avoid MPS being interrupted by signals
>
> in my fork because I observed worse "smoothness" in interactive use on
> macOS.

Eli said Helmut was working on fixing this commit for SIGIO/SIGPOLL,
which is most likely the problem (and implied I shouldn't work on that,
of course, because Eli).  OTOH, if we just fix the few remaining
handlers, it's safe to remove it.

> Is this commit still strictly necessary on non-macOS now that

I don't understand why you think this differs between macOS and
non-macOS.  The way macOS handles SIGSEGV does not make things any
safer: if a signal handler accesses MPS data we lose on any platform.

That said, there aren't that many signal handlers.  Definitely SIGINT
(accesses terminal data), technically SIGUSR (accesses symbol, string,
string data), probably more on Windows and Android.

> Helmut's changes for SIGPROF are in?

Helmut's changes for SIGPROF and SIGCHLD were present before that
commit.  They make SIGPROF safe, but discard data when igc_busy_p (),
which has false positives.  I don't understand why SIGCHLD needs a
fixed-size queue and function pointers rather than simply setting a
flag, but what it does now is safe.

igc_busy_p () uses pthread_trylock, but that seems safe on glibc.

> If not, I'd like to reverse it on scratch/igc.

I don't know what you decided wrt scratch/igc and Eli.  If we really
want to spend more time on signal handling we can remove it and fix the
remaining handlers; if we don't, special-case safe signals and leave it
in.

Pip

Re: scratch/igc: Avoid MPS being interrupted by signals

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> I don't know what you decided wrt scratch/igc and Eli.  

I just looked at the situation. The branch was stuck, the discussions
were stuck. Everyone is entitled to have his worries of course, but I'm
poking about in the fog why Eli is worried, and I'm obviously unable to
explain things well enough or induce enough trust to make this work.

That's why I think it's currently not wise pursuing a merge, at least
with the persons involved so far. It's too draining and in the end only
leads to ill feelings.

Whatever.

Someone from the outside is needed to solve this. Maybe Daniel can
explain things better. Or maybe one should ask Stefan Monnier to get
involved, or the other maintainers, I don't know. 

Not my problem, TBH. Being reckless again :-).

Re: scratch/igc: Avoid MPS being interrupted by signals

[Pip Cet via Emacs development discussions.]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>> I don't know what you decided wrt scratch/igc and Eli.
>
> I just looked at the situation. The branch was stuck, the discussions
> were stuck. Everyone is entitled to have his worries of course, but I'm
> poking about in the fog why Eli is worried, and I'm obviously unable to
> explain things well enough or induce enough trust to make this work.
>
> That's why I think it's currently not wise pursuing a merge, at least
> with the persons involved so far. It's too draining and in the end only
> leads to ill feelings.
>
> Whatever.

+1 to all of this.

I've kind of started collecting changes which Eli vetoed, but that
wasn't as much a conscious decision as it was "let's push this".  I need
to stop and think about what I want done with those.

> Someone from the outside is needed to solve this. Maybe Daniel can
> explain things better. Or maybe one should ask Stefan Monnier to get
> involved, or the other maintainers, I don't know.

Ah.  I wasn't sure whether your message was supposed to get more of a
reaction from Eli than it did.  I agree, in any case, that it would be
best for Someone Else to help solve this (but I'm not sure what to do if
that fails to happen).

Thanks!

Pip

Re: scratch/igc: Avoid MPS being interrupted by signals

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>
> Date: Wed, 08 Jan 2025 10:34:14 +0100
> 
> Pip Cet <pipcet@protonmail.com> writes:
> 
> > I don't know what you decided wrt scratch/igc and Eli.  
> 
> I just looked at the situation. The branch was stuck, the discussions
> were stuck. Everyone is entitled to have his worries of course, but I'm
> poking about in the fog why Eli is worried, and I'm obviously unable to
> explain things well enough or induce enough trust to make this work.
> 
> That's why I think it's currently not wise pursuing a merge, at least
> with the persons involved so far. It's too draining and in the end only
> leads to ill feelings.
> 
> Whatever.
> 
> Someone from the outside is needed to solve this. Maybe Daniel can
> explain things better. Or maybe one should ask Stefan Monnier to get
> involved, or the other maintainers, I don't know. 
> 
> Not my problem, TBH. Being reckless again :-).

I don't think I understand why you regard this so pessimistically.
The branch was not stuck, in the sense that no one, certainly not
myself, said commits couldn't be pushed to it.  The discussion wasn't
stuck, either, at least from my POV: we just reached the point where I
personally had nothing else useful to say on the subject.  Your
explanations (and those of Daniel and others) were helpful, and I
think at least I now understand the issues better.  I do still worry
that identifying all the situations where we'd need changes will be a
big and maybe long-term job, but since you-all say that either it
isn't such a big job or there's no way around it, I guess we will
wait-and-see.

Merging is also not an issue: I don't envision the branch landing in
the immediate future, so there's nothing to worry about.  I started
the discussion not because I wanted to land the branch right now, but
because I wanted to estimate how much more work is needed.

So I'm afraid I don't see a problem that needs to be solved here,
yours or SE's.  To answer Pip's question: there's no decision I know
about that must be made here.

But if someone disagrees, please do speak up.  These discussions are
held on emacs-devel precisely for that reason.

Re: scratch/igc: Avoid MPS being interrupted by signals

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I understand why you regard this so pessimistically.
> The branch was not stuck, in the sense that no one, certainly not
> myself, said commits couldn't be pushed to it.  The discussion wasn't
> stuck, either, at least from my POV: we just reached the point where I
> personally had nothing else useful to say on the subject.  

Well what I said is what I perceived.

What about your request to discuss changes on the branch before
committing? Is that off the table?

Re: scratch/igc: Avoid MPS being interrupted by signals

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  emacs-devel@gnu.org
> Date: Wed, 08 Jan 2025 15:08:34 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think I understand why you regard this so pessimistically.
> > The branch was not stuck, in the sense that no one, certainly not
> > myself, said commits couldn't be pushed to it.  The discussion wasn't
> > stuck, either, at least from my POV: we just reached the point where I
> > personally had nothing else useful to say on the subject.  
> 
> Well what I said is what I perceived.

I believe you.  Which is why I tried to explain the state of affairs
as I see them.

> What about your request to discuss changes on the branch before
> committing? Is that off the table?

I asked that about the patch which xstrdup's strings before putting
them into SAFE_NALLOCA'd array in callproc.c.  That was discussed
enough, and now is installed, so that issue is closed, from where I
stand.

I also asked to discuss each place where you suggest replacing
SAFE_ALLOCA and its ilk -- is that what you are asking about?

Re: scratch/igc: Avoid MPS being interrupted by signals

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> What about your request to discuss changes on the branch before
>> committing? Is that off the table?
>
> I asked that about the patch which xstrdup's strings before putting
> them into SAFE_NALLOCA'd array in callproc.c.  That was discussed
> enough, and now is installed, so that issue is closed, from where I
> stand.
>
> I also asked to discuss each place where you suggest replacing
> SAFE_ALLOCA and its ilk -- is that what you are asking about?

Yes, these. Long draining threads with indefinite outcome, from my POV,

It's good to hear now that you got something out of this you wanted to
know. But I would have found it nice if you would let me know. Others
too of course.

Or we let things just happen, discuss only if there are concrete
questions, or whatever. I don't know either. Main thing for me is to
avoid endless palaver where everyone is a bit dumber and drained in the
end.

Re: scratch/igc: Avoid MPS being interrupted by signals

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  emacs-devel@gnu.org
> Date: Wed, 08 Jan 2025 15:46:05 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> What about your request to discuss changes on the branch before
> >> committing? Is that off the table?
> >
> > I asked that about the patch which xstrdup's strings before putting
> > them into SAFE_NALLOCA'd array in callproc.c.  That was discussed
> > enough, and now is installed, so that issue is closed, from where I
> > stand.
> >
> > I also asked to discuss each place where you suggest replacing
> > SAFE_ALLOCA and its ilk -- is that what you are asking about?
> 
> Yes, these. Long draining threads with indefinite outcome, from my POV,

What can I do to make them shorter and more to the point?  I think
these discussions are important to establish the safe coding rules
when using MPS.

> It's good to hear now that you got something out of this you wanted to
> know. But I would have found it nice if you would let me know. Others
> too of course.

Sorry.

> Or we let things just happen, discuss only if there are concrete
> questions, or whatever. I don't know either. Main thing for me is to
> avoid endless palaver where everyone is a bit dumber and drained in the
> end.

Me too.

Re: scratch/igc: Avoid MPS being interrupted by signals

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: pipcet@protonmail.com,  emacs-devel@gnu.org
>> Date: Wed, 08 Jan 2025 15:46:05 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> What about your request to discuss changes on the branch before
>> >> committing? Is that off the table?
>> >
>> > I asked that about the patch which xstrdup's strings before putting
>> > them into SAFE_NALLOCA'd array in callproc.c.  That was discussed
>> > enough, and now is installed, so that issue is closed, from where I
>> > stand.
>> >
>> > I also asked to discuss each place where you suggest replacing
>> > SAFE_ALLOCA and its ilk -- is that what you are asking about?
>> 
>> Yes, these. Long draining threads with indefinite outcome, from my POV,
>
> What can I do to make them shorter and more to the point?  I think
> these discussions are important to establish the safe coding rules
> when using MPS.

Perhaps we all can simply keep that in mind. Let's see if we can do it
:-).

Re: scratch/igc: Avoid MPS being interrupted by signals

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: pipcet@protonmail.com,  emacs-devel@gnu.org
> Date: Wed, 08 Jan 2025 18:30:52 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Yes, these. Long draining threads with indefinite outcome, from my POV,
> >
> > What can I do to make them shorter and more to the point?  I think
> > these discussions are important to establish the safe coding rules
> > when using MPS.
> 
> Perhaps we all can simply keep that in mind. Let's see if we can do it
> :-).

Will do!

Re: scratch/igc: Avoid MPS being interrupted by signals

[Pip Cet via Emacs development discussions.]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Helmut's changes for SIGPROF are in? If not, I'd like to reverse it on

Oh, I see now you merged the delayed-SIGPROF thing.  I don't see why
that's necessary or desirable, but then that's true for all of SIGPROF
:-)

Re: scratch/igc: Avoid MPS being interrupted by signals

[Gerd Möllmann]

Pip Cet <pipcet@protonmail.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Helmut's changes for SIGPROF are in? If not, I'd like to reverse it on
>
> Oh, I see now you merged the delayed-SIGPROF thing.  I don't see why
> that's necessary or desirable, but then that's true for all of SIGPROF
> :-)

Well, then I'll revert that later, thanks!

Re: scratch/igc: Avoid MPS being interrupted by signals

[Pip Cet via Emacs development discussions.]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Pip Cet <pipcet@protonmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Helmut's changes for SIGPROF are in? If not, I'd like to reverse it on
>>
>> Oh, I see now you merged the delayed-SIGPROF thing.  I don't see why
>> that's necessary or desirable, but then that's true for all of SIGPROF
>> :-)
>
> Well, then I'll revert that later, thanks!

I didn't mean "I don't see why" as "I'm sure that's not true".  Maybe I
missed something about SIGPROF.  Might be best to ask Helmut :-)