What do you think about it?

Symfony EventDispatcher was designed like hook dispatcher, not "true" event dispatcher. Async processing doesn't make sense for hooks, so it leads to confusion.

Imho, this is totally off the business of the event dispatcher. For example, when I got an Event, which is bound to a domain model. When I'm now exchanging the event dispatcher with the async one, it's not transparent. It requires dependencies to make it actually work, e.g. the consumer command, the information transport ("transformers") etc.

We implemented the same stuff with a few 100 lines of code (including tests) & less overhead.

Imho this RFC should be published as an infrastructural bundle with clear dependencies, documentation, rather than putting it into core. Not everything needs to be "core". Imho the Symfony core should focus on stability, performance, security and features for 80%+ projects, not 2% enterprise.

Besides that, I don't think "Async Event Dispatcher" is the right name. It's basically a message queue and should be named as it. An "Async Event Dispatcher" which would be really transparent with the behaviour of the current event dispatcher, would be something like https://gist.github.com/havvg/3852361, with direct control which event is dispatched async. This could be implemented transparently as in-memory queue by moving addAsyncEvent logic into dispatch making any event async, or by configuration etc. However this would be truly transparent.

For example, when I got an Event, which is bound to a domain model. When I'm now exchanging the event dispatcher with the async one, it's not transparent.

I'm not sure I understand this example. When you fire event, you don't care how exactly this thing (event dispatcher, event bus, etc.) will notify event handlers about this event. However, as I said above, Symfony EventDispatcher is not "pure" event dispatcher, it is hook manager that requires to have sync event dispatching, because it allows to modify event object and send it back.

On other hand, "pure" event dispatcher/bus is "one way" bus, so it's perfectly fine to have async event handlers, because there is no difference for initiator (the one who runs $this->eventBus->handle(new UserActivatedPremiumAccount(42))). Initiator doesn't care what, when and in which order will be notified, because he won't receive any feedback directly anyway.

Besides that, I don't think "Async Event Dispatcher" is the right name.

It turns out that "Event Dispatcher" is not right name for the Symfony component. :)
https://twitter.com/mathiasverraes/status/665237482326355968 https://twitter.com/mathiasverraes/status/665238383699091456

I agree with the naming differences, although in my experience "hook" is not used widely in the PHP world, but it's more like "event" and "messages", respectively. The latter one will be implemented as a message bus, and then you are the point you made: you have decoupled situation. At least that's my experience in the PHP world on this topic, and be revisiting some implementations around "events" and "messages" it's common sense to some degree. I have also seen many of those implementations to be named "event bus" to make it clear, it's kinda "message bus/queue".

Let the "wrong" name be; it would be even more important to not coin something with a similar name working completely different, and putting something like "it's transparent" into its description - that's my whole point.

Just to clarify on the "transparent"; I actually meant, what you mean by transparent:

This could be implemented transparently as in-memory queue by moving addAsyncEvent logic into dispatch making any event async, or by configuration etc. However this would be truly transparent.

I think lazy services are a good example for what I mean. It's configured only (composer.json + attribute) and that's it. It just works™, no cohered implementation required. As you said, your setup require steps to do, and more important: maintain (e.g. supervisord).

I agree with you on the client - the callee of dispatch- transparency. But it's not transparent within the system as opposed to e.g. lazy services.

Don't get me wrong on this, I like the idea as it. I'm just concerned about making it part of the core.

The async events feature could be enabled per event listener and you (as a developer) choose what events you want to be processed asynchronously.

I understand your point, but I'm trying to say, that it is not clear, for example, when async event handler with higher priority executes later than sync event handler with lower priority. The same question goes to the stopPropogation method: what should happen when you call it from sync event handler? Does it mean that async handlers should be interrupted as well? Also, some developers might be confused when they mutate event object (and this is acceptable in the Symfony EventDispatcher), but ->dispatch() method won't return these changes. All these confusions come from the fact that the Symfony component wasn't designed for async behavior in the first place.

We have async event handlers in Symfony EventDispatcher as well, but we don't use this tool directly. We use our own EventBus contract with our own Event interface without mutators (stopPropogation, setName, etc.) to make it clear that you can't affect initial procedure and other event handlers. You can find some implementation details here: #18873. Internally, we have 2 instances of the EventDispatcher (for sync and async event handlers) and EventBus triggers dispatch of the sync event dispatcher and puts Event to the queue for async one. In config developer has to specify behavior by choosing right DI-tag. So it's possible to solve this issue without changes in the Symfony core and in more explicit way for developers.