| Hey Ian, 
 It presents a simpler means of synchronization, allows the client to
    block in an OS-independent way, and mimics the API of the MQTT
    client libraries in other languages. A wait() function as the sole
    blocking call is a common pattern in other modern asynchronous
    libraries: Microsoft Async, C++11 threads/futures. the Paho Java
    client library, etc. I'm not a GUI guy, I'm an RTOS guy, and do this
    pattern a lot, where a completed action always signals an OS
    synchronization object, but also fires an optional callback if the
    user requested it.
 
 In particular, as I originally mentioned, I'm trying to make the C++
    API mimic the Java one as much as possible, like:
 
 mqtt::itoken tok = client.publish("some topic",
      myMessage);I can work around this in the C++ library by intercepting the
    callbacks, but two issues make this a little more complicated due to
    to the outgoing "send" thread in the C lib:// Do something else for a while
 tok.wait_for_completion();
 
 
 (1) There doesn't appear to be a way to get the MQTTAsync_token of a
    message when you send it. And thus it's difficult to tie a token to
    the message.
 
 (2) Upon return of the send/sendMessage calls, the message has
    "disappeared" into the queue of the send thread. It doesn't appear
    in the list of outgoing messages (MQTTAsync_getPendingTokens) until
    some time later. So it is easy for the app to think that all
    messages were sent when some have yet to even be queued for
    transmission.
 
 Thanks for your time,
 Frank
 
 
 On 05/20/2013 05:30 AM, Ian Craggs
      wrote:
 
      
      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
 
 
 
 
 _______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/paho-dev
 
 |