Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Paho c client questions

Hi Juergen,

thanks for your comments.

1)  Interesting.   We should have a bug to consider this one.

2) NULL checks for malloc are handled in Heap.c. The malloc call is overridden. This will result in error messages in the trace. However, the question is what should the action be in the case of malloc failure? I guess the best solution is that the API call returns with failure - memory error. However that would add considerable complexity and code for handling the error and cleaning up partially allocated memory structures. The Paho embedded clients are intended for use in really small environments - they do not allocate any heap memory.

3) It is intended to be thread safe.

4) Guarantee is a strong word! But yes, the callbacks should be made. If you can get a trace of the situation where the callback is not made, that would be ideal. Trace is controlled by environment variables and for the async client, also with API calls.

Ian

On 09/09/2014 01:27 PM, Denner, Juergen wrote:
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

_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

--
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Committer on Paho, Mosquitto



Back to the top