Hi, did you experience this - what can I do to prevent it?
[dbus-1-tqt] WARNING: Attempt to call dispatch() recursively was silently ignored to prevent lockup!
This happens from Dialog, that I run with exec() and want to get return value
regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2018/10/11 02:05 AM, deloptes wrote:
Hi, did you experience this - what can I do to prevent it?
[dbus-1-tqt] WARNING: Attempt to call dispatch() recursively was silently ignored to prevent lockup!
This happens from Dialog, that I run with exec() and want to get return value
regards
Hi Emanoil, can you be a bit more clear on how to reproduce this? I am not sure I have understood. Cheers Michele
Michele Calgaro wrote:
Hi Emanoil, can you be a bit more clear on how to reproduce this? I am not sure I have understood. Cheers Michele
Hi Michele, I was wondering if someone has hit this issue. It comes from dbus-1-tqt, but does not hurt the application.
I think the problem is in the nature of the DBus call. You probably recall that I am playing recently with dbus-1-tqt and auto generated code (for bluetooth). Unfortunately dbusxml2qt3 does not generate the asynchronous methods out of the introspectable xml. I think this is the problem as the nature of the call in question is logically asynchronous.
It is long to explain how to reproduce it, but here is a brief summary.
1. generate interface for agent mkdir agent cd agent rm -f ./*.h ./*.cpp && /usr/bin/dbusxml2qt3 org.tdebluez.agent.xml 1.1 you need to fix #include agent1.h => agent1interface.h 2. implement (the example from the TDE wiki) 3. implement dialog that is started with exec() and is called in RequestConfirmation 4. call pair with device (from dbus or code)
=> when dialog window pops up - it blocks and those messages come with thousands until you press the button.
This makes me think an async method would be more appropriate here. I will try in the next days and report back. Perhaps we can extend dbusxml2qt3 to create async calls as well.
Let me know what you think, if you have some ideas.
thanks and regards
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2018/10/11 02:34 PM, deloptes wrote:
Michele Calgaro wrote:
Hi Emanoil, can you be a bit more clear on how to reproduce this? I am not sure I have understood. Cheers Michele
Hi Michele, I was wondering if someone has hit this issue. It comes from dbus-1-tqt, but does not hurt the application.
I think the problem is in the nature of the DBus call. You probably recall that I am playing recently with dbus-1-tqt and auto generated code (for bluetooth). Unfortunately dbusxml2qt3 does not generate the asynchronous methods out of the introspectable xml. I think this is the problem as the nature of the call in question is logically asynchronous.
It is long to explain how to reproduce it, but here is a brief summary.
- generate interface for agent mkdir agent cd agent rm -f ./*.h ./*.cpp && /usr/bin/dbusxml2qt3
org.tdebluez.agent.xml 1.1 you need to fix #include agent1.h => agent1interface.h 2. implement (the example from the TDE wiki) 3. implement dialog that is started with exec() and is called in RequestConfirmation 4. call pair with device (from dbus or code)
=> when dialog window pops up - it blocks and those messages come with thousands until you press the button.
This makes me think an async method would be more appropriate here. I will try in the next days and report back. Perhaps we can extend dbusxml2qt3 to create async calls as well.
Let me know what you think, if you have some ideas.
thanks and regards
Hi Emanoil, give me some time to look at this with more attention in the next week or two. This week I won't be able to give it much time. Cheers Michele
Michele Calgaro wrote:
give me some time to look at this with more attention in the next week or two. This week I won't be able to give it much time.
No problem with me Michele, I appreciate the support at any time. I will just try with an async call in the context if possible - need to investigate.
thanks and regards
deloptes wrote:
No problem with me Michele, I appreciate the support at any time. I will just try with an async call in the context if possible - need to investigate.
I looked yesterday, so following is happening:
1. App is sending async Pair request to the device 2. Device responds and org.bluez.Agent1.RequestConfirmation is called 3. RequestConfirmation runs a dialog (Ok|Cancel) and the worning is displayed 1000s of times until user confirms/rejects
Note: the class implementing RequestConfirmation is not (T)Q_OBJECT class but creates and runs the dialog. (not sure if this is related)
It might be that I also misunderstand the way it has to be implemented, but it might be that there is a reason for this wawrning in dbus-1-tqt
Last but not least, it is just a worning and code works as expected.
-
deloptes -
Michele Calgaro