From: "Lawrence Velázquez" <larryv@zsh.org>
To: zsh-workers@zsh.org
Subject: Re: [PATCH] Do not send duplicate signals when MONITOR is set
Date: Sun, 18 Jul 2021 18:55:08 -0400 [thread overview]
Message-ID: <bbd7b9e7-81fa-4244-8bc1-de7dffcb839a@www.fastmail.com> (raw)
In-Reply-To: <823a57a39d8873ce30d2806d95a1c540cf0fe2f2.camel@ntlworld.com>
On Mon, Jun 14, 2021, at 3:19 PM, Peter Stephenson wrote:
> On Mon, 2021-06-07 at 11:45 -0700, Bart Schaefer wrote:
> > On Mon, Jun 7, 2021 at 10:28 AM Erik Paulson <epaulson10@gmail.com> wrote:
> > >
> > > I run emacs as a daemon and use the emacsclient program to connect to
> > > it. I noticed that when I suspended the emacsclient program and
> > > resumed it in zsh, the program would sporadically crash. After digging
> > > into the code, I realized that emacsclient was receiving two SIGCONTs,
> > > which caused it to send a malformed command to the daemon.
> > >
> > > I found that this return used to be present, but was removed in
> > > https://www.zsh.org/mla/workers/2018/msg01338.html while addressing
> > > another emacs issue.
> >
> > I don't think it was removed ... similar code was added in two
> > separate places, but the "return" was only added in one of those.
> >
> > Your patch adds that return in the second case.
> >
> > The difference is that in the first case, the SIGCONT is received by a
> > job that is marked STAT_SUPERJOB and in the second case it's received
> > by a different job.
> >
> > I believe this means that in the former case the superjob is in the
> > foreground and in the second case, it isn't -- rather one of its
> > subjobs is. In the first instance zsh sends the signal to all the
> > subjobs and then to the process group. In the second case it sends
> > the signal to the process group first and then falls into the loop
> > sending the signal to any subjobs that still appear to be stopped.
> >
> > In any case I think a potential problem with placing an unconditional
> > "return" where your patch does, is that signals other than SIGCONT
> > probably still need to be delivered to the subjobs. PWS, any input
> > here?
>
> Hmm, it's not clear to me in what cases you'd need to deliver both
> killpg() to the group leader and then kill to the processes. You might
> hope if the shell was doing the right thing the first would be enough.
> But there might be special cases.
>
> I would hazard that as SIGCONT is probably the most difficult case ---
> the only one where you specifically want the process to be running
> afterwards --- if this patch improves things there, it's prohably not
> doing a lot of harm in most cases.
>
> It's not impossible there are some oddities where process groups aren't
> set up quite how you want that this might affect, but I doubt we're
> going to spot them just by staring.
Anything else on this?
--
vq
next prev parent reply other threads:[~2021-07-18 22:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-07 17:27 Erik Paulson
2021-06-07 18:45 ` Bart Schaefer
2021-06-14 19:19 ` Peter Stephenson
2021-07-18 22:55 ` Lawrence Velázquez [this message]
2021-07-19 10:00 ` Peter Stephenson
2021-07-23 20:11 ` Peter Stephenson
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=bbd7b9e7-81fa-4244-8bc1-de7dffcb839a@www.fastmail.com \
--to=larryv@zsh.org \
--cc=zsh-workers@zsh.org \
/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.vuxu.org/mirror/zsh/
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 NNTP newsgroup(s).