TL;DR, you propose adding a ResettableServiceInterface and call reset() on kernel.terminate.

This ResettableServiceInterface looks like a good idea to me, but not in Symfony unfortunately: a service (any class really) shouldn't know about its container. But requiring classes to implement ResettableServiceInterface would break this rule.

This might be something for PHP-FIG thought.

For the 2 issues you spotted, I think we have to find more specific solutions - just not this one...

the fact that this forces any package containing a memomizing class to depend on the package defining the interface is precisely what I highlighted in #23975 as major pain point to implement such an idea.

@stof @nicolas-grekas I got it now and you are right, it should something for PHP-FIG.

Given that Symfony is leader in PHP world, does it make sense to implement it here and when PSR is created one day, move to it like ContainerInterface was?

It would work only for bundles at beginning but I think it is a good start.

@nicolas-grekas About

For the 2 issues you spotted, I think we have to find a solution - just not this one..

Can a simple public function reset() be added to DoctrineType::class to avoid reflection?

public function reset() be added to DoctrineType::class

with a doctrine listener that would call it on terminate? you should give it a try in a PR yes

A component should not care about whether it's constructed and managed by a container or not. Also, a library like Doctrine for instance should not have an opinion on what kind of data needs to be flushed for a new request. This is why I also would oppose such an interface.

However, for the bundle that registers a component as a set of services, it's a different story. DoctrineBundle could reset the EM, FrameworkBundle could reset the form type you mentioned, WebProfilerBundle could flush data collectors that would leak memory otherwise. So if a generic cleanup mechanism would be implemented, the framework should imho hand over the responsibility to the bundles.

Bundles could register event handlers that to do the cleanup work. I could see the following approaches:

• Each bundle registers its own listeners to the kernel.terminate event and does its cleanup there. Since cleaning up is not necessary in shared-nothing environments (which is php's default, after all), those listeners should be opt-in. The result would be that I had to turn on those cleanup tasks in each bundle's configuration. This might not be the perfect way, but it would be possible without changing the framework itself.
• A new event kernel.reset (or similar) is added that would only be triggered in environments like phppm. This would work as with the kernel.terminate event, but the bundles don't need to take care of the opt-in to the reset anymore. They simply register their cleanup tasks on that new event.

The event handlers in both approaches have the downside that they might unnecessarily reset a service that has not been constructed yet. Alternatively, we could try to solve this with the container. The container builder would receive a mechanism to configure method calls that reset a service.

services:
    some_service:
        class: Acme\SomeService
        on_reset:
            - myResetMethod
            - ['@some_other_service', anotherResetMethod]

The container would have a reset() (or you name it) method that would iterate over all constructed services with that configuration and call the configured methods.

@derrabus it might be worth pursuing the generic idea (the per-bundle-listener-style has many drawbacks you spotted so it doesn't look worth it to me.)

So, about the generic one:

A new event kernel.reset

why a new event? kernel.terminate looks just fine to me, isn't it?

unnecessarily reset a service that has not been constructed yet

I would try so resist as much as possible to the need for a new config option, but the concern is valid.
We do have $container->initialized() for public services. But that leaves the issue open for private ones.

Another option would be to have a new type of service arguments (similar to IteratorArgument) that yields instances only if they are already initialized.
With such a primitive, we could then use a tag, eg. kernel.resettable, and make everything work with a compiler pass and a generic event listener: the event listener would call a reset() method on all instantiated services on kernel.terminate.

Would that make sense? Would you like to give it a try?

Just out of curiosity: shouldn't it be enough to reset all instantiated services by setting $this->services = [] in the container?

In theory it could, but this wouldn't clear the static properties (if any leak comes from there). It wouldn't also clear circular references - unless an explicit call to the garbage collector is done. But planning for resetting all services + triggering the GC might defeat most of the perf benefit of php-pm-like strategies.
Having explicit cooperation from services that "leak" might be a more robust solution.

I'm not sure about this proposal, but it would be great to make Symfony 100% compatible with PHP-PM, for those devs who want to use it. In #18244 @marcj pointed out the biggest problem to make that happen.

@NicoHaase Yes, you could do that, but the idea of phppm is to gain speed by not throwing everything away between requests. So keeping constructed services and only deleting request-related data from them is the desirable behavior here.

One could also think about just unsetting those services that carry request-related data, but then we might get strange behavior in services that have already consumed the service we've just unset.

@nicolas-grekas For me, the question whether we solve this with a config option or a tag is the question if we make this a feature of the container itself (=> config option) or a feature that FramworkBundle adds to the component (=> tag + compiler pass).

I don't want to bloat the container, but I think this feature could be useful for projects that use the container without the framework.

why a new event? kernel.terminate looks just fine to me, isn't it?

If we don't take the approach of event handlers registered by bundles, we don't need a new event. I simply wanted to move the decision whether cleanup event handlers are necessary or not out of the bundles. After all, preparing the application for another request was not the original purpose of kernel.terminate. It just happens to be the last event in the cycle.

Another option would be to have a new type of service arguments (similar to IteratorArgument) that yields instances only if they are already initialized.

I don't see a generic use-case in such a feature. Also, the content of that iterator might change after each request. This could make its behavior unpredictable and volatile.

Would you like to give it a try?

I'll work on a prototype and see how it works out.

this feature could be useful for projects that use the container without the framework

if we can do it with frameworkbundle, without patching DI, it means anyone can do it also.
to me, the tag + compiler pass + event listener belong to HttpKernel, DI needs this primitive to get uninitialized services, and framework just some config to wire things together

about uninitialized services, you still need a way to (not) deal with them, how would you do it then?

See #24033 for uninitialized services

Hello, this post may be a little bit out of topic but it's about the part of "promoting phppm".

I don't see how phppm could replace the bin/console server:run if you consider that its power comes precisely from the fact it doesn't need to get classes on each HTTP call, which is exactly what we expect in a development environment. Does phppm support hot-reload or something like that?

About the rest: that's awesome trying to move on a real support for phppm. This is really interesting. Thanks for your work Symfony Team!!! 😄

@Nek- Yes, php-pm does support "hot reloading".

@Nek- see php-pm/php-pm#14

@derrabus #24033 is now merged.

To sum up the plan we talked about on Slack:
in HttpKernel, we could add a compiler pass to manage a kernel.reset (or kernel.resettable) tag, taking a "method" attribute (<tag name="kernel.reset" method="reset">)
still in HttpKernel, an EventSubscriber would then be registered on kernel.terminate to call all those methods.
The list of services to reset would be passed to the event subscriber as an iterator of initialized-only services (see #24033).

Once ready, we could leverage that feature and review components per components the services that would need this resettable behavior to comply with php-pm&the-likes.

We could also add a "ResettableInterface" in HttpKernel, so that this behavior could be easily autoconfigured.

@nicolas-grekas Please have a look at #24155.

See #24232 and doctrine/DoctrineBundle#695 that should fix the DoctrineEntity-related issue.

Thank you guys, this kernel.reset is amazing thing and very simple to use.

Happy to close this one, that's a great step forward :)