[paho-dev] Design question - how to best approach background tasks for t

[Ian Craggs <icraggs@xxxxxxxxxxxxxxxxxxxxxxx>]

Hello all,

as I've been updating the C "high level" embedded client for FreeRTOS:

(http://git.eclipse.org/c/paho/org.eclipse.paho.mqtt.embedded-c.git/commit/?h=develop)

I've been pondering how to best have background tasks completed.   I 
originally envisaged two styles of APIs, similar to the standard Paho C 
client libraries, synchronous and asynchronous.  I haven't yet created 
the asynchronous version, but that would use a background thread, at the 
cost of using more resources.

The "synchronous" or blocking API would be easy to use, and all 
processing would take place on the application's thread.  Because no 
separate threads were involved, this would both simplify implementation 
and reduce resource usage.  To allow messages to be received, there is a 
yield() call, which takes as its parameter a time to run.  The API also 
has a a function (or method) called cycle(), which processes one 
incoming MQTT packet.  Yield() just calls cycle() under the covers.  I 
didn't originally intend to make cycle() a public function.

The problem with yield() is that it might spend most of its time doing 
nothing.  An MQTT packet might arrive at the end of the timeout period, 
and not get processed until the next call to yield().   One solution is 
to make cycle() a public function and allow the application to 
interleave application with MQTT processing at a fine-grained level.

For FreeRTOS I was considering also a background task to be started.  
But this would still have the negative effects of increased resource 
usage and complexity as synchronization of the common data structures 
would be needed.  So I'm reconsidering this once more, and thinking of 
leaving the background thread to an (almost) totally non-blocking API.

I had also been thinking of changing the semantics of yield() in some 
way to be more event driven.  But I don't know whether this would buy 
any advantages over making cycle() a public function.

Thoughts?

--
Ian Craggs
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto