You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mosquitto-2.14.0 (I saw no related changes according to Changes).
I think I found a bug with an return code of mosquitto_loop_stop, I think in a "nothing to do" situation is erroneously returns MOSQ_ERR_INVAL.
If mosquitto is in threaded mode (mosquitto_loop_start() called before connect), then at shutdown applications must mosquitto_disconnect, and wait for disconnect callback and then call mosquitto_loop_stop, which sometimes fails.
With gdb, I saw that after disconnect the mosquitto_loop_forever() gets MOSQ_ERR_NO_CONN from mosquitto_loop (to not much surprise, since disconnect was called). In this case, loop_forever calls mosquitto__get_state() which is mosq_cs_disconnected, so run is set to zero, which ends both while (run) loops and returns to mosquitto__thread_main(). This (probably for another use case) does:
If the main thread comes to call mosquitto_loop_stop after that, loop_stop finds mosq->threaded != mosq_ts_self and returns MOSQ_ERR_INVAL.
I think mosq->threaded is used to check if loop_stop needs to terminate an own thread (and here, it already ended, so it does not need to do so). but at least the return value is wrong.
However, at least if disconnect fails, I think the application must call mosquitto_loop_stop to ensure the thread is away.
NB: At the end there also is a difference, not sure if of importance if someone may connect again: if mosquitto_loop_stop won the race and was faster, mosq->thread_id is pthread_self (the thread from the application), but if disconnect / mosquitto__thread_main() won, it still seems to contain the thread_id of the non-existing mosquitto__thread_main() thread.
As a workaround, I think I can ignore MOSQ_ERR_INVAL from loop_stop, but I think this could be improved.
Also I wonder whether mosquitto_log_callback should be called with some messages if the thread_main exits, as this may be a very helpful information.
The text was updated successfully, but these errors were encountered:
Hi,
mosquitto-2.14.0 (I saw no related changes according to Changes).
I think I found a bug with an return code of mosquitto_loop_stop, I think in a "nothing to do" situation is erroneously returns
MOSQ_ERR_INVAL
.If mosquitto is in threaded mode (mosquitto_loop_start() called before connect), then at shutdown applications must mosquitto_disconnect, and wait for disconnect callback and then call mosquitto_loop_stop, which sometimes fails.
With gdb, I saw that after disconnect the mosquitto_loop_forever() gets MOSQ_ERR_NO_CONN from mosquitto_loop (to not much surprise, since disconnect was called). In this case, loop_forever calls mosquitto__get_state() which is
mosq_cs_disconnected
, sorun
is set to zero, which ends bothwhile (run)
loops and returns to mosquitto__thread_main(). This (probably for another use case) does:and the thread ends.
If the main thread comes to call mosquitto_loop_stop after that, loop_stop finds
mosq->threaded != mosq_ts_self
and returnsMOSQ_ERR_INVAL
.I think mosq->threaded is used to check if loop_stop needs to terminate an own thread (and here, it already ended, so it does not need to do so). but at least the return value is wrong.
However, at least if disconnect fails, I think the application must call mosquitto_loop_stop to ensure the thread is away.
NB: At the end there also is a difference, not sure if of importance if someone may connect again: if mosquitto_loop_stop won the race and was faster, mosq->thread_id is pthread_self (the thread from the application), but if disconnect / mosquitto__thread_main() won, it still seems to contain the thread_id of the non-existing mosquitto__thread_main() thread.
As a workaround, I think I can ignore MOSQ_ERR_INVAL from loop_stop, but I think this could be improved.
Also I wonder whether mosquitto_log_callback should be called with some messages if the thread_main exits, as this may be a very helpful information.
The text was updated successfully, but these errors were encountered: