Making libaquaero5 a shared library could make it easier for applications to use it.
But as the library is not stateless, we would have to make sure concurrent calls to any library function never result in an inconsistent state. So besides from checking the current state at the beginning of most of the functions, we should make them thread-safe.
IMHO, there would be another benefit from all this: caching!
We could add a parameter for the polling functions that indicates how "fresh" the resulting readout shoud be. The library could then check if there already exists a (fresh enough) data buffer and return its data instead of polling the device again. This would solve some scalability problems if you think of running many aerotools-enabled applications in parallel (e.g. a data logging daemon, a cli tool and an applet in the window manager).
Making libaquaero5 a shared library could make it easier for applications to use it.
But as the library is not stateless, we would have to make sure concurrent calls to any library function never result in an inconsistent state. So besides from checking the current state at the beginning of most of the functions, we should make them thread-safe.
IMHO, there would be another benefit from all this: caching! We could add a parameter for the polling functions that indicates how "fresh" the resulting readout shoud be. The library could then check if there already exists a (fresh enough) data buffer and return its data instead of polling the device again. This would solve some scalability problems if you think of running many aerotools-enabled applications in parallel (e.g. a data logging daemon, a cli tool and an applet in the window manager).