git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Michael J Gruber <git@grubix.eu>
Subject: Re: [PATCH] http.c: clear the 'finished' member once we are done with it
Date: Tue, 24 May 2022 01:41:02 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2205240124280.352@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqqr14jluu4.fsf@gitster.g>

Hi Junio,

On Mon, 23 May 2022, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I stumbled over the need for this while investigating the build failures
> > caused by upgrading Git for Windows' SDK's GCC to v12.x.
> >
> >> diff --git a/http.c b/http.c
> >> index 229da4d148..85437b1980 100644
> >> --- a/http.c
> >> +++ b/http.c
> >> @@ -1367,6 +1367,9 @@ void run_active_slot(struct active_request_slot *slot)
> >>  			select(max_fd+1, &readfds, &writefds, &excfds, &select_timeout);
> >>  		}
> >>  	}
> >> +
> >> +	if (slot->finished == &finished)
> >> +		slot->finished = NULL;
> >
> > First of all, I suspect that
> > https://github.com/git/git/blob/v2.36.1/http.c#L1207 makes sure that GCC's
> > complaint is not actually accurate: we always re-set `finished` to `NULL`
> > when getting an unused slot, so even if there is a left-over dangling
> > pointer, it is not actually used, ever.
> >
> > But we need something to pacify GCC. Let's look at your patch.
> >
> > The first thing to note is that this is not _quite_ thread-safe: between
>
> Does this part of the code ever run multi-threaded?

It calls into cURL, which I suspect has a multi-threaded mode of
operation, and we do use some callbacks in `http-walker.c` and I was
worried that these callbacks could be called via cURL calls. That's why I
am concerned about thread-safety. I have looked for a while and not found
any way that code in `http.c` or `http-walker.c` could set `finished` by
way of a cURL callback, but there is a lot of code there and I could have
missed something crucial.

> > If that analysis is correct, I would expect the correct solution to turn
> > `finished` into an attribute of the slot, and change its role to be a flag
> > that this slot is spoken for and cannot be re-used quite yet even if it is
> > not currently in use.
>
> I have a feeling that we've mentioned that at least twice (perhaps
> three times) in the recent past that it is in essense reverting what
> the "finished" change baa7b67d (HTTP slot reuse fixes, 2006-03-10)
> did.  We used to use the in-use bit of the slot as an indicator that
> the slot dispatched by run_active_slot() has finished (i.e. the
> in-use bit must be cleared when the request held in the struct is
> fully done), but that broke when a slot we are looking at in
> run_active_slot() is serviced (which makes in_use false), and then
> another request reuses the slot (now no longer in_use), before the
> control comes back to the loop.  "while (slot->in_use)" at the
> beginning of the loop was still true, but the original request the
> slot was being used for, the one that the run_active_slot() function
> cares about, has completed.
>
> So...

No, I suggested to replace the `finished` variable with an attribute (or
"field" or "member variable") of the slot, and to respect it when looking
for an unused slot, i.e. not only look for a slot whose `in_use` is 0 but
also require `reserved_for_use` to be 0. In essence, the
`run_active_slot()` function owns the slot, even if it is not marked as
`in_use`. That should address the same concern as baa7b67d but without
using a pointer to a local variable.

Ciao,
Dscho

  parent reply	other threads:[~2022-05-23 23:41 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 18:04 [PATCH 0/2] quell a few gcc warnings Michael J Gruber
2022-05-06 18:04 ` [PATCH 1/2] dir.c: avoid gcc warning Michael J Gruber
2022-05-06 20:21   ` Junio C Hamano
2022-05-09 15:58     ` Taylor Blau
2022-05-07  6:14   ` Carlo Marcelo Arenas Belón
2022-05-06 18:04 ` [PATCH 2/2] http.c: " Michael J Gruber
2022-05-06 20:22   ` Junio C Hamano
2022-05-06 21:17     ` [PATCH] http.c: clear the 'finished' member once we are done with it Junio C Hamano
2022-05-07  5:40       ` Carlo Marcelo Arenas Belón
2022-05-07 18:42         ` Junio C Hamano
2022-05-07 19:11           ` Carlo Arenas
2022-05-23 21:58       ` Johannes Schindelin
2022-05-23 22:58         ` Junio C Hamano
2022-05-23 23:36           ` Junio C Hamano
2022-05-23 23:41           ` Johannes Schindelin [this message]
2022-05-24  0:02             ` Junio C Hamano
2022-05-24  6:31               ` Daniel Stenberg
2022-05-24 10:57                 ` Johannes Schindelin
2022-05-24 17:45                 ` Junio C Hamano
2022-05-26 14:15                   ` Daniel Stenberg
2022-05-24 11:03               ` Johannes Schindelin
2022-05-24 17:15                 ` Junio C Hamano
2022-05-24 20:16                   ` Carlo Marcelo Arenas Belón
2022-05-24 20:45                     ` Ævar Arnfjörð Bjarmason
2022-05-24 22:34                       ` Junio C Hamano
2022-05-25  9:08                         ` Michael J Gruber
2022-05-25 13:27                         ` Ævar Arnfjörð Bjarmason
2022-05-24 22:16                     ` Junio C Hamano
2022-05-24 23:19                     ` Junio C Hamano
2022-05-25  2:02                       ` Carlo Arenas
2022-05-24 20:38                   ` Ævar Arnfjörð Bjarmason
2022-05-24 22:28                     ` Junio C Hamano
2022-05-25 10:07                       ` Johannes Schindelin
2022-05-25 16:40                         ` Junio C Hamano
2022-05-06 20:41   ` [PATCH 2/2] http.c: avoid gcc warning Carlo Marcelo Arenas Belón
2022-05-09 11:22 ` [PATCH] detect-compiler: make detection independent of locale Michael J Gruber
2022-05-09 15:52   ` Junio C Hamano
2022-05-09 15:59     ` rsbecker

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: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2205240124280.352@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@grubix.eu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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://80x24.org/mirrors/git.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).