[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[paho-dev] Paho c client questions
|
Hello,
I'm currently playing around with the paho c client (current git-master branch/2014-09-04 13:06:27) and wrapping it with a C++ layer.
I cannot use the existing cpp wrapper since C++11 is (currently) not a valid option for me.
Consuming the asynchronous client was straightforward and real fun.
While implementing the C++ wrapper and an evaluation scenario, the following questions came up.
1) MQTTAsync_token
There is a race condition that makes the usage of the MQTTAsync_token in publish, subscribe, unsubscribe potentially complicated.
It is possible that these methods return *after* the onSuccess or onFailure callback already has been invoked.
This happens if the MQTTAsync_addCommand is already invoked but the method (publish, subscribe, unsubscribe) did not return because of the OS scheduler.
So creating any structure related to the token is potentially too late.
A potential option would be that MQTTAsync_responseOptions contains a callback that is invoked before the internal
MQTTAsync_addCommand is invoked and after the token is known. Just thoughts ...
[This is correlated to Bug 433871 but with a different aim.]
2) NULL checks
There are no NULL checks on malloc. The current implementation will end up with segmentation faults on low memory situations.
I assume this is not uncommon on small devices.
3) Thread safety of the client not documented.
I assume that send must not be used concurrently by multiple threads.
The usage of MQTTProtocol_assignMsgId seems not thread save to me. If this was never intended than it's just a documentation question.
4) Callback invocation guarantee
I currently need to do a cleanup on the provided context for callback methods.
Unluckily it seems not to be guaranteed that either onSuccess or onFailure is invoked. Especially where MQTTAsync_disconnect is invoked immediately after a send.
This requires bookkeeping for contexts in the wrapping component. Is this behavior intended?
In my current evaluation, the most striking issue is the context cleanup.
In this mail I've tried to document my initial experience and simply summarized my findings and questions on first contact with the library. I hope this input is beneficial.
Best Regards,
Jürgen
