|Re: [paho-dev] Python client: threaded interface problem|
are you using some locks in our callbacks ? There is some issue with locks/deadlock when callbacks are using locks ( and ). I don't yet had time to look at them, but I want to improve locks for the next release.
Your workaround may produce error, since loop_start should not be called if you manually call loop() since this may unexpected error .
Before I had time to looks at those locks issue, if your workaround which call loop() works, you may drop loop_start() and only rely on calling loop() yourself. But if are going this way, you should make sure loop() is called at least every keepalive and enough to process incoming message. So, if your client is only sending message, and more than 1 per minutes, your are fine.
Le 22/03/2019 à 20:28, Ben Kinsella a écrit :
I have an intermittent problem with my Python client implementation, and I'm looking for some help.I am trying to create a minimal test case, but the problem seems to be dependent on timing, which suggests a race condition.
My code looks like this (simplified):
...client = mqtt.Client(client_id=self.ecn, clean_session=False, userdata=None, protocol=mqtt.MQTTv311, transport="tcp")...(configure callbacks etc.)...client.connect(host, int(port), keepalive=60)client.loop_start()self.ms_client = client
...message_info = self.ms_client.publish(topic, payload=json.dumps(payload), qos=2, retain=False)message_info.wait_for_publish()
The problem is that wait_for_publish() never returns.
If I remove it, then everything works fine, and my on_publish() callback is called as expected.But I want to handle each publish synchronously.
I tried replacing wait_for_publish() with is_published() as follows:
while not message_info.is_published():time.sleep(1)
But the result is the same. The code just hangs.What is interesting is that if I replace time.sleep() with a call to loop():
while not message_info.is_published():self.ms_client.loop(1)
This works!Does this suggest a deadlock in the threaded interface?
I have looked through the GitHub issues, and #309 sounded somewhat related.But this was fixed in 1.4, and I have tested both 1.3 and 1.4 and both display the problem.
Steve Cope's website mentions some "strange behaviour" when using loop_start().Does this suggest there may be a race condition in the threaded interface?
Any other suggestions appreciated,Ben.
_______________________________________________ paho-dev mailing list paho-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/paho-dev
paho-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
Back to the top