Does Disruptor support asynchronous EventHandler? about disruptor-net HOT 4 CLOSED

In the Disruptor, every IEventHandler has a dedicated executor thread that synchronously and sequentially processes the events. It performs very well if you can split your application processing pipeline in a few well-defined steps. Of course, you can also group multiple steps into a single IEventHandler.

The best way to use the Disruptor is to have more cores than event handlers to avoid context switches. In this situation, you will not gain much with async IO, especially if you need to wait for the operation to complete before processing the next event. I would advise to use synchronous IO here, because blocking your thread is not an issue and because async IO often have a small overhead (at least a few allocations, but often more than just allocations).

If you only have an async API, you can simply Wait for the task to finish. Synchronously waiting on a task (sync over async) is often an anti-pattern, but in this case you are waiting in the event handler dedicated thread, not from a thread-pool thread, so you will not have deadlock issues.

I hope this helps.

from disruptor-net.

The Disruptor can be useful for IO bound use cases, particularly for networking, because you benefit from the good latency and you can use the batching to properly handle queuing. If latency is not an issue, for example for non-critical disk IO, you still benefit from the batching.

If you have a low-throughput, IO bound scenario with a one-step pipeline, then you probably do not need to use the Disruptor 🙂.

from disruptor-net.

I just thought that it would be possible to add a useful async handler support in the Disruptor. An API could be added to register multiple IAsyncEventHandler together. They would be run in the same dedicated thread and awaiting in an handler would allow the previous handler to process the next entry. But I feel like it would be a very niche use-case.

from disruptor-net.

@ocoanet thanks for you reply, which inspired me a lot, And after think it twice, I found for my case, i.e. IO-bound scenario, the throughput is usually not very high, the bottleneck usually is not queuing system, but the IO itself. So I probably just use simple queues for my use cases.

And for Disruptor, I think your idea is really great. The only thing I am thinking is, just as my cases, is Disruptor needed for IO bound cases? It might depend on the business logic of the application.

from disruptor-net.