Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] python: implicit loop_stop on disconnect, multiple clients, watchdogs 
Trying to re-sent the message correctly formated...

I didn't re-checked the code, but from memory:
* Yes disconnect cause the loop to terminate. IIRC it's because the loop had somehow a "while is_connected || want_to_reconnect" loop
* I believe the terminate loop on disconnect is a wanted feature because it allow to call "loop_forever" from main thread and exit it using disconnect() on a callback.   Maybe this feature should use an option (disconnect(terminate_loop=True/False) ?), since I agree in your case it's unexpected to require to restart the loop.
* I confirm that multiple client is supported and means starting a loop per client.
* I'll check about the GC'ed behavior, but I highly suspect the client and the loop will be leaking if loop isn't stopped.
* Yes it's a multi-threading mess with the callback. They are indeed called currently called from the loop thread which could imply locking issue.
I'll apply your suggestion on the documentation to make those point more clear. 

PierreF

Le 18/02/2025 à 07:53, Pierre Fersing via paho-dev a écrit :

Hi,

I didn't re-checked the code, but from memory:
* Yes disconnect cause the loop to terminate. IIRC it's because the loop had somehow a "while is_connected || want_to_reconnect" loop * I believe the terminate loop on disconnect is a wanted feature because it allow to call "loop_forever" from main thread and exit it using disconnect() on a callback. Maybe this wanted feature should use an option (disconnect(terminate_loop=True/False) ?), since I agree in your case it's unexpected to require to restart the loop. * I confirm that multiple client is supported and means starting a loop per client. * I'll check about the GC'ed behavior, but I highly suspect the client and the loop will be leaking if loop isn't stopped. * Yes it's a multi-threading mess with the callback. They are indeed called currently called from the loop thread which could imply locking issue. I'll apply your suggestion on the documentation to make those point more clear. PierreF 

Le 17/02/2025 à 16:57, Peter Silva via paho-dev a écrit :

That makes sense as a work-around, and I'll try that for sure.
I guess the question that arises is whether that is how it "should" be... 
Do other language bindings do the same thing?


On Mon, Feb 17, 2025 at 10:46 AM Greg Troxel <gdt@xxxxxxxxxx> wrote:

    Peter Silva via paho-dev <paho-dev@xxxxxxxxxxx> writes:

    > It would make more sense (principle of least surprise) to me
    that the loop_
    > controls would be independent of connection state. I don´t think
    > connect/disconnect should mess with the loop at all. And one of the 
    > features in my having active subscriptions to more than one
    broker at a
    > time... So this is doubly relevant.  If one broker is broken, I
    don´t want
    > the disconnect to break the other.  I will get this working with
    AMQP
    > first, but then immediately turn to do the same with MQTT.

    As I read the code, the loop is per client object.  Each object can
    connect to one broker.

    I think you just need to call loop_start every time you call connect
    (assuming you call connect only once after start or disconnect).


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev 
_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev

Back to the top