|
A deliberate choice. Why have one
blocking call in an asynchronous API which is designed for GUI
use, amongst others? This is an event-oriented API - use the
deliveryComplete callback. To receive messages with MQTTAsync,
you have to use callbacks. You have to use callbacks to determine
the success of API calls.
For a blocking, simpler to use API, with less use of callbacks,
there is MQTTClient.
Ian
On 19/05/13 19:06, Frank Pagliughi wrote:
Well, while I'm throwing sand in the works, I might as well
continue...
One thing that appears to be "missing" from the C async API is the
ability to block a thread on a token while waiting for an action
to complete. Something like:
int MQTTAsync_waitForCompletion(MQTTAsync handle,
MQTTAsync_token token, int timeout);
This would prevent the app from wasting CPU cycles while spinning
on a flag from a callback, and can simplify client apps that don't
need the full power of a callback function by eliminating the need
for them for basic synchronization. Plus it would allow the user
to write more portable client apps, since the library would hide
the OS-specific thread functionality.
It appears that the library already wraps condition variables in
Linux. Maybe Windows could use a Manual Reset Event to do this?
Frank
|
