Mosquitto_loop_start() details needed

Tech Talk
1

As I understand this function creates the separate thread which must be terminated by mosquitto_loop_stop() on application exit. There’re several things not covered in the documentation.

  1. does this thread perform reconnection to the broker in case connection is lost? Description of mosquitto_loop_forever() explicitly states this, but mosquitto_loop_start() does not detail for this behavior. If not, what is the best practice reconnecting to broker when using mosquitto_loop_start()?;
  2. may mosquitto_loop_start() call its callbacks, in particular message callback, in parallel? For example by forking its thread - or is it guaranteed that if I start thread using mosquitto_loop_start() the callbacks will be only called once and new callback will not happen until I finish with current one? My problem here that I plan do to certain operations in callback, and these operations can not be paralleled because they use specific single-access medium.

Thank you!

2

Hi Eugeny,

  1. Looking into the implementation of the mosquitto_loop_start (in lib/thread_mosq.c) we can see the function creates excactly one thread and invokes mosquitto_loop_forever form this new created thread.
    So the mosquitto_loop_start is the direct counterpart to the mosquitto_loop_forever and therefore behaves exactly the same way regarding required reconnects.
  2. As this thread started inside mosquitto_loop_start is the only thread started in the mosquitto client library all callbacks will be invoked one after the other by this thread. On the other hand this means you will block the whole incoming/outging message handling, if you block this thread for too long in your callback function.

The good thing in open source projects is you may always look into the source, if you have doubt about the details :slight_smile:

Best
Norbert

1 Like
3

I did that but wanted someone else to validate my findings as suspect that what I see is not up to my ideal understanding on how it must work :slight_smile:

Thank you very much for your reply. The blocking is intended because if there would be multithreaded way of operation I would need to make synchronizers which I want to avoid.