Until recently I was involved in the development of a library to be used for acquiring data from a hardware device via a server application. The server application sends out messages via a ZMQ connection whenever it has received data, and the library spins up a thread that checks if data can be received from its ZMQ connection in a regular interval.
My question is now how to properly pass this received data on to the hosting application, given that it lives in a separate thread context, while the main thread is outside of the control of the library. Our solution so far was to basically just execute callbacks from that thread itself. However, a colleague remarked that this puts the responsibility of handling thread synchronisation to the implementing party, and they need to be aware that the callback function they register needs to make sure it doesn't cause data corruption on the main thread.
The alternative that said colleague suggested would basically be an event system, which would work by queueing up the received data somewhere in the main thread context and providing users of the library with functionality to trigger processing of that event queue and evocation of the respective callbacks. That, however, places the responsibility to keep the event loop running at the host side, and it potentially introduces delays in data processing, if the event queue is not processed frequently enough. In any case, immediate data forwarding (i.e. processing data further as soon as it arrives) would likely not be possible this way.
I honestly don't know how performance-critical immediate processing of that data from the library is for those who implement it, so the latter use case may not be of high relevance. Nevertheless, I'm curious to know which way to make data accessible for a host application is considered "better style".