Results 1 to 20 of 20

Thread: regarding Qt::BlockingQueuedConnection

  1. #1
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default regarding Qt::BlockingQueuedConnection

    Hi everyone,
    Let me explain my problem through an example. I have 2 different classes both running in different threads.
    Qt Code:
    1. A.h (header file)
    2. Class A
    3. {
    4. public:
    5. A();
    6. signals:
    7. void sigA();
    8. private slots:
    9. void slotA();
    10. }
    11.  
    12. A.cpp (source file)
    13. A::A()
    14. {
    15. emit sigA();
    16. }
    17. void A::slotA()
    18. {
    19. //some processing
    20. }
    21.  
    22. B.h
    23. Class B
    24. {
    25. signals:
    26. void sigB();
    27. private slots:
    28. void slotB();
    29. }
    30.  
    31. B.cpp
    32. void B::slotB()
    33. {
    34. emit sigB();
    35. }
    36.  
    37. main.cpp
    38. void main()
    39. {
    40. A objA;
    41. B objB;
    42. QObject::connect(&objA, SIGNAL(sigA()), &objB, SLOT(slotB()), Qt::BlockingQueuedConnection);
    43. QObject::connect(&objB, SIGNAL(sigB()), &objA, SLOT(slotA()), Qt::BlockingQueuedConnection);
    44. }
    To copy to clipboard, switch view to plain text mode 

    In short I am emitting sigA which is connected with slotB. From slotB I am emitting sigB which is connected with slotA. And both the connections are in BlockingQueuedConnection mode. As a result the application is going into deadlock when the following step is executed :-
    Qt Code:
    1. emit sigB();
    To copy to clipboard, switch view to plain text mode 
    .
    If I remove Qt::BlockingQueuedConnection from the connection between sigB and slotA then it's fine. But I want both to be in BlockingQueuedConnection i.e I want sigA to hang/wait until slotA hasn't finished executing. Can anyone explain me why deadlock is happening and how to achieve the same without causing deadlock?


    -With regards,
    sattu

  2. #2
    Join Date
    Mar 2008
    Location
    Kraków, Poland
    Posts
    1,530
    Thanked 281 Times in 276 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    From QObject doc : Same as QueuedConnection, except the current thread blocks until the slot returns. This connection type should only be used where the emitter and receiver are in different threads. Note: Violating this rule can cause your application to deadlock. You are emmitting signal to thread which is blocked so You have what You do.
    Maybe You should use QuedConnection and synchronise threads with mutex ?

  3. The following user says thank you to Lesiok for this useful post:

    sattu (14th March 2013)

  4. #3
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,014 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: regarding Qt::BlockingQueuedConnection

    Why do you think you need a blocking queued connection?
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  5. #4
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by Lesiok View Post
    From QObject doc : Same as QueuedConnection, except the current thread blocks until the slot returns. This connection type should only be used where the emitter and receiver are in different threads. Note: Violating this rule can cause your application to deadlock. You are emmitting signal to thread which is blocked so You have what You do.
    Great, since I am emitting signal to a thread which already is blocked so it results in a deadlock. Understood,
    Maybe You should use QuedConnection and synchronise threads with mutex ?
    Well, my whole purpose is that sigA should wait until slotA has finished executing. But the problem is slotA is called when sigB is emitted from slotB. I will look into QuedConnection but I am not sure how mutex may help me in this case.

    Quote Originally Posted by wysota View Post
    Why do you think you need a blocking queued connection?
    If i want a signal to wait until the connected slot is finished executing, then I should use blocking connection, right?

  6. #5
    Join Date
    Nov 2010
    Posts
    315
    Thanked 53 Times in 51 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows Symbian S60 Maemo/MeeGo

    Default Re: regarding Qt::BlockingQueuedConnection

    The whole concept of signal and slot is "fire and forget". Qt::BlockingQueuedConnection is just spatial case needed only when slot should return some value (for example in some cases of DBus usage). When you don't send data back from slot to signal then use of BlockingQueuedConnection is redundant.

    QueuedConnection works like that: Qt packages signal parameters and send it as event to event loop respective to the receivers thread. When event loop of that thread gains control, parameters are unpacked and proper slot is called. Event loop HAS TO gain control to make things happen.
    Difference in case of BlockingQueuedConnection is that signal doesn't return (blocks) until it revives information that all slots has processed signal (control returns to event loop), so if you are sending back a signal also with BlockingQueuedConnection then you have a dead lock. Both signals are waiting until other tread returns control to respective event loop.

  7. The following user says thank you to MarekR22 for this useful post:

    sattu (14th March 2013)

  8. #6
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,014 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by sattu View Post
    If i want a signal to wait until the connected slot is finished executing, then I should use blocking connection, right?
    I'm asking you why you want to wait.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  9. #7
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by MarekR22 View Post
    The whole concept of signal and slot is "fire and forget". Qt::BlockingQueuedConnection is just spatial case needed only when slot should return some value (for example in some cases of DBus usage). When you don't send data back from slot to signal then use of BlockingQueuedConnection is redundant.
    Correct. But when I need to know in sender thread whether slot(in receiver thread) has finished executing or not, then the only option is BlockingQueuedConnection, right? Yes, the slot is not returning any value, but at the same time signal should wait until the connected slot has finished executing. So, is there any other alternative for such scenarios?


    Added after 37 minutes:


    Quote Originally Posted by wysota View Post
    I'm asking you why you want to wait.
    Well, the scenario is little bit complex but still I will try to explain.
    SCENARIO-- I have a sensor thread and a tcp-client thread. Whenever sensor captures some biometric data, it will send the captured data to the tcp-client thread. The tcp-client will in turn send the biometric information to a remote authentication server which will respond with a "yes" or "no". When the tcp-client thread(which is waiting for the remote server's response) gets the response from server, it will immediately relay it back to the sensor thread. So, I require 2 pairs of signal-slot connection. One for sensor-to-tcpclient and another for the reverse.
    PROBLEM-- But until tcp-client hasn't replied with the authentication response, sensor thread should wait. This is where my confusion begins .
    MY APPROACH-- Since using of 2 BlockingQueued Connection was out of question, so I solved it temporarily by using a boolean variable in my sensor class i.e once I have sent the data to the tcpclient class the variable becomes true and it won't become false until the time I haven't got the response back from tcpclient.

    But I am sure there must be a much better way to achieve the same. Like just now I saw that there is a method in tcpclient class which is :-
    waitForReadyRead ( int msecs )
    .
    Sorry for taking such a long time to reply but all the way I was thinking how to reply in a very short and precise way


    Added after 8 minutes:


    Or maybe instead of taking a separate thread for tcpclient, I can directly declare it's object in my sensor class and connect it's readyread() signal with a slot of sensor class. So after doing
    Qt Code:
    1. objClient->write(sendData);
    To copy to clipboard, switch view to plain text mode 
    I can call
    Qt Code:
    1. objClient->waitForReadyRead();
    To copy to clipboard, switch view to plain text mode 
    which will cause my sensor thread to hang until I haven't received response from server. Once I have received the data my readyreadslot() will immediately be called and I can get the response in the sensor class only.
    Last edited by sattu; 14th March 2013 at 16:13.

  10. #8
    Join Date
    Dec 2012
    Posts
    90
    Thanks
    5
    Thanked 20 Times in 18 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    You can use states, say your sensor thread has two states: idle and data processing.
    Whenever sensor thread is in idle state it waits for biometric data to be input, then when it acquires it it sends it to client and changes state to data processing.
    So now it can respond to further events (say gui updates, or user cancel event, etc)
    Meanwhile tcp client does authentication, and after it completes it send nonblocking signal with the result to the sensor thread.
    The sensor thread then do what it need to do with the result and switching back to idle state.

  11. The following user says thank you to lanz for this useful post:

    sattu (15th March 2013)

  12. #9
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,014 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: regarding Qt::BlockingQueuedConnection

    I say scrap all the threads and use regular signals and slots. If I ever hear "networking thread" or "tcp thread" again I think I might explode.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  13. The following user says thank you to wysota for this useful post:

    jboban (3rd April 2013)

  14. #10
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by wysota View Post
    I say scrap all the threads and use regular signals and slots. If I ever hear "networking thread" or "tcp thread" again I think I might explode.
    Okies, sure sure . Now I am confused why in the first case I even thought of using 2 pairs of signal-slots, that too both in blocking mode. My bad . Thanks once again,

  15. #11
    Join Date
    Jan 2006
    Location
    Graz, Austria
    Posts
    8,419
    Thanks
    37
    Thanked 1,546 Times in 1,496 Posts
    Qt products
    Qt3 Qt4 Qt5
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    It is not your fault, a lot of frameworks require setups like this.

    As lanz indicated one alternative is to describe the states your program can be in and then just to event based processing.
    Can be done in a separate thread but might not be necessary. This mainly depends whether you can read from the sensor in a non-blocking way.

    Cheers,
    _

  16. The following user says thank you to anda_skoa for this useful post:

    sattu (18th March 2013)

  17. #12
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    Thanks a lot anda_skoa. Discussing here I got a lot of clarifications. As Wysota said I don't even need to implement a separate thread. It works fine without it .

  18. #13
    Join Date
    Jun 2011
    Posts
    12
    Thanks
    6
    Qt products
    Qt3 Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows Android

    Cool Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by wysota View Post
    If I ever hear "networking thread" or "tcp thread" again I think I might explode.
    Absolutely right! Many people think that must wait for TCP/Network work or slows down his programs. Instead, TCP is buffer and you don't have to waste the time waiting on it. Just write to it, and let event loop runs.

    P.S. I'v solved my problem by reorganizing protocol. Thanks.

  19. #14
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by jboban View Post
    Absolutely right! Many people think that must wait for TCP/Network work or slows down his programs. Instead, TCP is buffer and you don't have to waste the time waiting on it. Just write to it, and let event loop runs.
    You should not reply without properly understanding the post. Anyone working in the domain of socket programming knows that TCP is a buffer and you don't have to wait after writing the data. And that's the exact reason why you have 2 different approach to TCP programming- synchronous and asynchronous. But in some cases you need to wait for the response after writing data to the socket. And my post was regarding those "some cases". And I definitely am not "wasting my time waiting for the response" because that's what the requirement is. Send a request to SERVER and wait for it's response.

  20. #15
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,014 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by sattu View Post
    Anyone working in the domain of socket programming knows that TCP is a buffer and you don't have to wait after writing the data.
    Anyone working in the domain of socket programming should also know the buffer is limited and can be filled completely when there is congestion in the network which can block your application for an indefinite amount of time.

    But in some cases you need to wait for the response after writing data to the socket.
    I don't think that's the case. If you decide to wait then that's your choice but you certainly don't need to wait. You can happily do other things while the data is not there and come back to where you left off when data arrives. Logically you'll still be "waiting for data" but physically you will have those resources available for other tasks. This is safer in terms of both security and durability.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  21. #16
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by wysota View Post
    If you decide to wait then that's your choice but you certainly don't need to wait. You can happily do other things while the data is not there and come back to where you left off when data arrives. Logically you'll still be "waiting for data" but physically you will have those resources available for other tasks. This is safer in terms of both security and durability.
    Yes Sir, but in my case it's about requirement, not choice. And my requirement is such that application should not do anything until data/response is received from server. Mine is an "Authentication" model. Client should wait until either server authenticates or timeout happens. So all this stuff

  22. #17
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,014 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by sattu View Post
    Yes Sir, but in my case it's about requirement, not choice. And my requirement is such that application should not do anything until data/response is received from server. Mine is an "Authentication" model. Client should wait until either server authenticates or timeout happens. So all this stuff
    "Not do anything" and "wait" are two different things. If You choose to "not do anything" by waiting then that's your choice but it is not the only (and most probably not the most farsighted) approach. What if you want to cancel authentication? What if you need to authenticate against more than one entity at the same time? You can't do any of those with a blocking approach.
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  23. #18
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by wysota View Post
    What if you want to cancel authentication?
    I can't because I am using a state parameter to disable all the keypress events until authentication completes or timeout happens. I mean I don't want the user to navigate to any other screen until authentication happens. But yes, I never thought of this question before. If I have to add "cancellation" part then I have to refine the code further or maybe change it altogether. As I told my intention here is not to allow the user to change the screen (even if by mistake) until the process is completed.
    What if you need to authenticate against more than one entity at the same time?
    This should not be a problem because basically my application is not hanging. Only the Keypress part is disabled till completion of process.
    You can't do any of those with a blocking approach.
    Nooooooooooooooooo. I am not using blocking approach . I am using a state variable for maintaining the status but application is free to process anything that may be required during this "waiting" time.

  24. #19
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,364
    Thanks
    3
    Thanked 5,014 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by sattu View Post
    As I told my intention here is not to allow the user to change the screen (even if by mistake) until the process is completed.
    This is usually done either by disabling the UI or by opening a "please wait" modal dialog on top of it. If you block the UI then for example windows will not be redrawn and you'll be getting ugly gray rectangles on your UI.

    This should not be a problem because basically my application is not hanging.
    If you make blocking calls to the socket (or whatever else that blocks, e.g. BlockingQueuedConnection) then your application is hanging.

    I am not using blocking approach . I am using a state variable for maintaining the status but application is free to process anything that may be required during this "waiting" time.
    So why the heck did you write this and cause confusion:
    But in some cases you need to wait for the response after writing data to the socket
    jboban's statement was perfectly fine so why did you start arguing with it?
    Your biological and technological distinctiveness will be added to our own. Resistance is futile.

    Please ask Qt related questions on the forum and not using private messages or visitor messages.


  25. #20
    Join Date
    Sep 2010
    Location
    Bangalore
    Posts
    169
    Thanks
    59
    Qt products
    Qt4 Qt/Embedded
    Platforms
    Unix/X11 Windows

    Default Re: regarding Qt::BlockingQueuedConnection

    Quote Originally Posted by wysota View Post
    If you make blocking calls to the socket (or whatever else that blocks, e.g. BlockingQueuedConnection) then your application is hanging.
    So why the heck did you write this and cause confusion:
    Don't know what to say. Whether or not to use "BlockingQueuedConnection" was my doubt. That's why I named my topic like that. But then as Lanz suggested, I can instead go for the use of states and you also replied that "separate threads are not at all necessary". And that's what I am doing now. I am not creating any confusion. The post was regarding my doubt (i.e BlockingQueuedConnection) and the conclusion was that there are better alternative approaches for it. So I wrote "I am not using blocking approach" (because this topic got solved a long time back).

    jboban's statement was perfectly fine so why did you start arguing with it?
    Yaa correct, his statement was PERFECTLY fine. My mistake, leave it.

Similar Threads

  1. Replies: 3
    Last Post: 2nd January 2012, 11:57
  2. Replies: 7
    Last Post: 27th December 2011, 13:28
  3. Replies: 5
    Last Post: 27th December 2011, 11:09
  4. BlockingQueuedConnection hang
    By ^NyAw^ in forum Qt Programming
    Replies: 7
    Last Post: 17th February 2010, 18:30
  5. Replies: 1
    Last Post: 6th November 2009, 18:33

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.