All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: phillip.wood@dunelm.org.uk
Cc: Taylor Blau <me@ttaylorr.com>, Patrick Steinhardt <ps@pks.im>,
	git@vger.kernel.org, iwiedler@gitlab.com
Subject: Re: [PATCH 1/1] fetch: fix deadlock when cleaning up lockfiles in async signals
Date: Mon, 10 Jan 2022 21:11:20 -0500	[thread overview]
Message-ID: <YdznSPJCSUQwVyg8@nand.local> (raw)
In-Reply-To: <2d8c1619-74ab-62b3-3a30-8e500a16649e@gmail.com>

On Sat, Jan 08, 2022 at 10:54:35AM +0000, Phillip Wood wrote:
> > But is unlink() safe as-is? I'm not so sure. Reading signal-safety(7),
> > it's clearly on the list of functions that are OK to call. But reading
> > the errno section:
> >
> > (snip)
> >
> > We certainly not doing that, though that's nothing new, and so I wonder
> > why it doesn't seem to be an issue in practice.
>
> Because in this case we re-raise the signal and exit it does not matter if
> unlink() clobbers errno. If instead the program were to continue after
> handling the signal then we would have to save and restore errno to avoid
> interfering with the code that was running when the signal handler was
> called.

That makes perfect sense to me. Thanks for a clear explanation.

Taylor

  reply	other threads:[~2022-01-11  2:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-07 10:53 [PATCH 0/1] Async-signal safety in signal handlers Patrick Steinhardt
2022-01-07 10:55 ` [PATCH 1/1] fetch: fix deadlock when cleaning up lockfiles in async signals Patrick Steinhardt
2022-01-07 11:14   ` brian m. carlson
2022-01-07 22:41   ` Taylor Blau
2022-01-08 10:54     ` Phillip Wood
2022-01-11  2:11       ` Taylor Blau [this message]
     [not found] <cover.1641551066.git.ps@pks.im>
2022-01-07 10:53 ` Patrick Steinhardt

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=YdznSPJCSUQwVyg8@nand.local \
    --to=me@ttaylorr.com \
    --cc=git@vger.kernel.org \
    --cc=iwiedler@gitlab.com \
    --cc=phillip.wood@dunelm.org.uk \
    --cc=ps@pks.im \
    /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.
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.