What does an EventLoop do?

Brad

Yet another great question and I hope this is useful to others.

Before I attempt to explain some of the DDS APIs I'd like to explain the underlying requirements. OpenICE is envisioned as allowing the user to interact with a shard of a larger distributed data store which is automatically coordinated with other nodes of the system. In other more modern systems "reactivity" is built in at quite a low level to such a system. In other words libraries and APIs acknowledge certain components as "reactive". This enables concepts like declarative data binding where the relationship between two changing data elements can be "bound". Actually a lot of OpenICE code is devoted to adapting DDS structures to the JavaFX version of reactive collections and data elements which can then be "bound" to UI elements. The pattern is actually useful beyond UIs and declarative data binding code can be, in many cases, more expressive and predictable.

The rest of my response will focus on the DDS APIs which do not work in this way. Each DDS entity may emit status changes as an event. Readers also emit changes to contained data in a similar fashion. The EventLoop is an "event loop" in the traditional sense but in OpenICE it is used most often to handle DDS events. As opposed to considering "events" equivalent to "messages" in message-oriented middleware it's better to think of them more generically because the same suite of events are always generated by DDS related to the underlying user data. "Events" here are not composed by the user as in a message oriented middleware. Therefore the creation/disposal of keyed data instances are two types of events. The new availability of data samples for an instance is another type. Each DDS "Entity" can emit a variety of events.

There are three options for the handling of events in "user level" code. Perhaps the simplest strategy is polling. If ultra low latency is prioritized well ahead of resource usage you can poll a DDS entity for status changes with get_status_changes() Or if the DATA_AVAILABLE status is what you are interested in you could poll with repeated calls to read or take.

Another simple strategy is to receive callbacks from the DDS libraries when data or events are available to process. This is a simple way to get started either by passing a listener into a constructor at entity creation time or utilizing set_listener calls. While this is super convenient it's best for rapid handling of events only (perhaps enqueuing them into another processing system) because internal DDS threads are being used to deliver events to you. Any blocking of that callback thread could change the behavior and performance of DDS.

The third option is communication via condition variables and WaitSets. These tools allow you to block your thread until any of a set of conditions becomes active. For instance a single thread could service several DataReaders by adding ReadConditions from those readers to a WaitSet. The EventLoop is something I built to manage this in a manner similar to existing event handling loops (like glib). It allows one to register a variety of conditions and callbacks for handling those conditions. The EventLoop is driven by an external thread (see EventLoopHandler). In a more complex system this might be a thread pool but for now it's a single thread so that handlers don't require reentrancy (which simplifies a lot of things greatly).

So in essence the EventLoop is a way to centralize handling of various DDS events onto a particular thread. This is less wasteful of CPU cycles than polling and it is less likely to affect the operation of internal DDS threads. It also ensures that the handling of events is synchronized in one thread simplifying concurrency.

I hope this is helpful. An EventLoop is NOT required to utilize DDS but with de-coupled component-based software all interacting with DDS in-process this is a helpful piece of infrastructure.

Keep the great questions coming!

Thanks
Jeff

Thank you - that answered my question and did a nice job of framing the DDS capabilities within OpenICE and the broader set of patterns of responses to data.