Limitations of channels.EventBus

[jonathandung]

The current middleware system of channels.EventBus remembers the order of the middlewares, which is usually crucial to getting the correct data across. It does not, however, allow insertion at any position, which is sometimes desirable.

Also, O(1) insertion and removal of middlewares means that the middleware must be a hashable callable. For unhashable callables, functions must be made to wrap them, which is annoying.

Besides, the underlying implementation (using a hash map) disallows duplicate middlewares. Again, to work around this, wrapper functions must be used in place of the function containing the processing steps. This is troublesome.

However, a method to get the best of both worlds (performance and flexibility) is not known.

[jonathandung]

Possible fixes and corresponding issues

• Using a list is indeed flexible, but insertion and removal, even if the index is known, slows to O(n).
• Using a linked list with node references works. However, it would be difficult to expose the node references suitably without requiring additional storage.
• It is possible to use a list together with a hash map. The list acts as a registry, giving each callable, hashable or not, an id corresponding to its length at that moment. Then the hash map stores maps ids to futures, and removal removes from the hash map only, which is O(1). But then the registry would have to be cleaned up periodically, which would mean acquiring some lock for both the list and the hash map. This prevents publishing whenever cleanups are running, and garbage collection would be a nightmare.