On Mon, Nov 11, 2024 at 10:29 PM Patrick Steinhardt <ps@xxxxxx> 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@xxxxxx> 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
