Does anyone have example processing loop code using EPOLL or libuv

[gbrackley]

Hi,

I want to have an event processing loop that can also service additional low throughput file descriptor events/timers. From what I can see the connection implementation doesn't allowing adding more file descriptor to the poll loop (in the waitForNextRequest() method).

The comments in the IConnection.h indicate that getEventLoopPollData() can be used to implement your own loop. I can see how the sdbus file descriptor and events are exposed via this method. However I can't see how the internal event file descriptor (eventFd_) of the Connection class implementation is exposed, and assume this is also required to be polled with POLLIN.

The loopExitFd_ would be specific to my implementation and wouldn't need to be exposed or used.

Is my understanding correct? Has anyone implemented an external event loop thread? Can anyone share an example please? I'd prefer not to use block-copy inheritance of the Connection class. Thank you.

[sangelovic]

@gbrackley Hi, the support for external event loops is there in v1.x release line, but somewhat limited and problematic in some edge cases. In the upcoming v2.0 release (#364), the support is fixed, complete and a little better documented. See https://github.com/Kistler-Group/sdbus-cpp/blob/release/v2.0/docs/using-sdbus-c%2B%2B.md#using-sdbus-c-in-external-event-loops, which shall clarify how things shall be set up in an external event loop.

Also, v2.0 implements sd-event integration, built on top of IConnection::getEventLoopPollData(). See Connection::attachSdEventLoop() for a real-time code example on how the fd's are used an external event loop.

Do you have the possibility to already use v2.0 (currently in that feature branch, but soon to be merged to master)?

[gbrackley]

@sangelovic Thank you for the response. I had not been following the v2.0 branch. I've pulled it out and had a quick look and can see the expanded documentation and the support for both file descriptors.

With the project I am doing, I will wait for the v2.0 code to be released (with the hope that it gets merged in the next few months). The implementation is doing bluetooth, rauc and other low speed dbus i/o (absolute i/o throughput is not an issue). Having additional file descriptors on the same i/o thread would greatly simplify concurrency/locking, and reduce having to manage another thread.

What also seems clear is that I should be looking in the direction of libsystemd's sd-event (as you have pointed out) and not in the direction of libuv, libev, libevent, ...

[sangelovic]

Yes, v2.0 should be released in the upcoming week(s). I will ping you here. Having one I/O thread make sense, of course. Perhaps we can close the discussion thread now?