git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Calvin Wan <calvinwan@google.com>
Cc: git@vger.kernel.org, steamdon@google.com, emrass@google.com,
	me@ttaylorr.com, stolee@gmail.com
Subject: Re: [RFC PATCH 1/1] maintenance: separate parallelism safe and unsafe tasks
Date: Tue, 12 Nov 2024 07:28:59 +0100	[thread overview]
Message-ID: <ZzL1jy3plVeld_3m@pks.im> (raw)
In-Reply-To: <CAFySSZCzxfqpMWH5ORv8fYb7f5WU3Fc2N99fW33wD9JOcYVrVA@mail.gmail.com>

On Mon, Nov 11, 2024 at 10:06:10AM -0800, Calvin Wan wrote:
> On Sun, Nov 10, 2024 at 11:07 PM Patrick Steinhardt <ps@pks.im> wrote:
> > >       [TASK_LOOSE_OBJECTS] = {
> > >               "loose-objects",
> > >               maintenance_task_loose_objects,
> > >               loose_object_auto_condition,
> > > +             SAFE,
> > >       },
> > >       [TASK_INCREMENTAL_REPACK] = {
> > >               "incremental-repack",
> > >               maintenance_task_incremental_repack,
> > >               incremental_repack_auto_condition,
> > > +             SAFE,
> > > +     },
> > > +     [TASK_UNSAFE_GC] = {
> > > +             "unsafe-gc",
> > > +             maintenance_task_unsafe_gc,
> > > +             need_to_gc,
> > > +             UNSAFE,
> > > +             0,
> > > +     },
> > > +     [TASK_SAFE_GC] = {
> > > +             "safe-gc",
> > > +             maintenance_task_safe_gc,
> > > +             need_to_gc,
> > > +             SAFE,
> > > +             0,
> > >       },
> >
> > Hm. I wonder whether we really want to expose additional tasks to
> > address the issue, which feels like we're leaking implementation details
> > to our users. Would it maybe be preferable to instead introduce a new
> > optional callback function for every task that handles the pre-detach
> > logic?
> 
> This does sound like a good idea. However, would there be any issue
> with running all pre-detach logic before running post-detach logic?
> I'm thinking if pre-detach logic from a different function could
> affect post-detach logic from another. If not, I do agree this would
> be the best solution going forward.

Sure, in theory these can interact with each other. But is that any
different when you represent this with tasks instead? The conflict would
still exist there. It's also not any different to how things work right
now: the "gc" task will impact the "repack" task, so configuring them
both at the same time does not really make much sense.

Patrick

  reply	other threads:[~2024-11-12  6:29 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08 17:31 [RFC PATCH 0/1] maintenance: separate parallelism safe and unsafe tasks Calvin Wan
2024-11-08 17:31 ` [RFC PATCH 1/1] " Calvin Wan
2024-11-11  7:07   ` Patrick Steinhardt
2024-11-11 18:06     ` Calvin Wan
2024-11-12  6:28       ` Patrick Steinhardt [this message]
2024-11-15 20:13         ` Calvin Wan
2024-11-18  1:32           ` Junio C Hamano
2024-11-18  6:58           ` Patrick Steinhardt
2024-11-11  8:24   ` Junio C Hamano
2024-11-11  9:14   ` Junio C Hamano
2024-11-11 18:12     ` Calvin Wan
2024-11-11  4:50 ` [RFC PATCH 0/1] " Junio C Hamano
2024-11-11 18:39   ` Calvin Wan

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=ZzL1jy3plVeld_3m@pks.im \
    --to=ps@pks.im \
    --cc=calvinwan@google.com \
    --cc=emrass@google.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=steamdon@google.com \
    --cc=stolee@gmail.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.
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).