Ordering guarantees

[reactor]

Ordering guarantees

[smaldini]

Interesting, would it mean to make the current tasks queue shareable?

[smaldini]

(Also I think exposing the task queue would be interesting for storage/retry/metrics/etc)

[dynaxis]

Hi, I'm the person who wrote the reply quoted above. My concern is somewhat related to https://groups.google.com/forum/?#!topic/reactor-framework/9iUBl7lZZyc .

I got that reactor removes direct dependencies between event generators and consumers and is really fast at dispatching events. It is already a good aid for asynchronous programming in general. But it would be good if we don't need to care about explicit synchronization at all when writing consumers (especially with stateful consumers).

As you know, actors and some other in-VM messaging frameworks such as Jetlang try to do so by requiring programmers to concern only about message exchanges inside their application. No other synchronization is required. Here I'm roughly equating Consumers and actors (Fibers in Jetlang).

I'm afraid such a facility is not in the scope of Reactor possibly due to differences in the major design decision or something like that.

[dynaxis]

#55 seems relevant to this issue too.

[jbrisbin]

I think this issue is addressed by the Resequencer support now in master that enforces order on a Consumer by managing checkouts and checkins of slot numbers.

[smaldini]

As a side note, the latest changes in Dispatcher (e2f3a4b) also solve this, order is guaranteed for singleThreaded dispatcher (event Loop, Ring Buffer) where ThreadPool will redispatch to any available thread.