# Mosquitto\_loop\_start() details needed

**URL:** <https://forum.cedalo.com/t/mosquitto-loop-start-details-needed/511>\
**Category:** Tech Talk\
**Created:** [March 11, 2022, 10:13pm UTC](https://forum.cedalo.com/t/mosquitto-loop-start-details-needed/511 "2022-03-11T22:13:17Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Eugeny](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@Eugeny](https://forum.cedalo.com/u/Eugeny)\
**Post date:** [March 11, 2022, 10:13pm UTC](https://forum.cedalo.com/t/mosquitto-loop-start-details-needed/511/1 "2022-03-11T22:13:17Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![norbert](https://avatars.discourse-cdn.com/v4/letter/n/f6c823/32.png) [@norbert](https://forum.cedalo.com/u/norbert)\
**Post date:** [March 14, 2022, 10:27am UTC](https://forum.cedalo.com/t/mosquitto-loop-start-details-needed/511/2 "2022-03-14T10:27:46Z")

</div>

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 🙂

Best  
Norbert

---

<div class="post-metadata">

**Author:** ![Eugeny](https://avatars.discourse-cdn.com/v4/letter/e/bbce88/32.png) [@Eugeny](https://forum.cedalo.com/u/Eugeny)\
**Post date:** [March 14, 2022, 10:53am UTC](https://forum.cedalo.com/t/mosquitto-loop-start-details-needed/511/3 "2022-03-14T10:53:28Z")

</div>

> [@norbert](#):
>
> The good thing in open source projects is you may always look into the source, if you have doubt about the details 🙂

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 🙂

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.