LTTng » Babeltrace

Currently, when using the lttng-live source component class, the source component will return TRY_AGAIN if it has no messages to return but the connection is still open. The graph will return TRY_AGAIN to the user, which can then run the graph again to retry. The source component might have some data available, or it might also return TRY_AGAIN again. This effectively constitutes a busy loop, consuming CPU to check if new data is available.

It would be better to have the process block on a syscall if there's nothing to consume, and be woken up when some data arrives. Here's how I would see it:

1. A source that may return TRY_AGAIN would register a file descriptor to be used as an asynchronous event source, along with a callback
2. When a sink's consume method returns TRY_AGAIN, that sink is placed in the "inactive sinks" list
3. If there are no active sinks, bt_graph_run (or some new function) would poll all event sources, waiting for one to become readable.
4. It would call the callback associated to the event source(s) that became readable
5. The source component would send some kind of signal downstream that would trickle down to the sinks that previously became inactive, those sinks would inform the graph, who would put them back in the "active" list

Of course, many problems come to mind, such as how to deal with portability, multiple sinks where one keeps producing and one that becomes inactive and active again (how do you make sure not to starve the one that became inactive), how to evolve the API to include that without breaking any existing behavior, etc.