Re: [RFC PATCH 1/1] maintenance: separate parallelism safe and unsafe tasks

> On Mon, Nov 11, 2024 at 10:29 PM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > 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:
> > > >
> > > > 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.
> 
> No you are correct that this is no different than how these tasks are
> currently run. However, I have just received some numbers that the
> repack, when gc'ing in Android, is the longest operation so even if we
> were able to run repack first in the foreground, ultimately it
> wouldn't save a significant amount of time compared to running gc
> entirely in the foreground. I think for now it makes sense to hold off
> on rerolling this series (at least in the form of auto
> backgrounding/foregrounding tasks) since the purported benefits
> currently aren't worth the churn. Thanks again for the comments on
> this series