This message was deleted.

from the Gradle code: when the buildFinished event is emitted all the registered build services are ‘stopped’, which consists of calling

.close()

for those that are

AutoCloseable

. The listeners are added at registration time, and presumably are called in that order.

private <T extends BuildService<P>, P extends BuildServiceParameters> BuildServiceProvider<T, P> doRegister(
        String name,
        Class<T> implementationType,
        @Nullable P parameters,
        Integer maxParallelUsages,
        NamedDomainObjectSet<BuildServiceRegistration<?, ?>> registrations
    ) {
        BuildServiceProvider<T, P> provider = new BuildServiceProvider<>(
            buildIdentifier,
            name,
            implementationType,
            parameters,
            isolationScheme,
            instantiatorFactory.injectScheme(),
            isolatableFactory,
            services,
            listener
        );

        DefaultServiceRegistration<T, P> registration = uncheckedNonnullCast(specInstantiator.newInstance(DefaultServiceRegistration.class, name, parameters, provider));
        registration.getMaxParallelUsages().set(maxParallelUsages);
        registrations.add(registration);

        // TODO - should stop the service after last usage (ie after the last task that uses it) instead of at the end of the build
        // TODO - should reuse service across build invocations, until the parameters change (which contradicts the previous item)
        listenerManager.addListener(new ServiceCleanupListener(provider));
        return provider;
    }

Thank you! This is very helpful. I’m not sure we want to rely on this implementation detail, but we’ll think about it.

agreed, it is odd to rely on registration order - seems like the correct cleanup would follow the dependency graph. You could simulate that by using

Closeable

(instead of AutoCloseable), to avoid the flaky ordering, and then have a build service that listens for the buildFinished event and calls close on the service in the right order.

Thanks. Your idea seems like it could work, but it would mean doing significant build activity after buildFinished for us. We’d like to avoid that, I think we are just going to try to avoid having build services depend on close() ordering.

sounds good. seems like you’d be doing that same work, just in a controlled order, as

close()

today is triggered on the buildFinished event.