Important: Please read the Qt Code of Conduct -

Is signal-slot blocking.??

  • suppose i create an object of a class which has a slot. i connect this slot to any system signal like say readyRead() in constructor.

    can the execution of signal-slot, block my calling function, where i created instance of the class.??

  • Not sure, are you asking if the constructor could block on processing a signal? I think this could happen if you have a multithreaded application (therefore signals are coming independently from the thread that is building the instance).
    "This": could help.

  • Can you please rephrase your question. It is completely incomprehensible (to me).

    There is no way a slot connected in the constructor is execute before the constructor is finished, neither in single-threaded applications (the thread is executing your constructor) nor in multithreaded applications (the signal is dispatched as soon as the execution returns to the event loop, which happens in any case after the constructor has returned).

    I see this only happening if you <code>qApp->processEvents()</code> or <code>moveToThread(this)</code> in your constructor - both highly questionable. Rule of thumb: just don't do it.

  • no, this will not block the execution of your program.

  • If the question is whether emitting a signal blocks the caller until the slots have been called, then the correct answer is "it depends".

    In a single-threaded case, signal-slot connections are direct connections, meaning the slots get called when the signal is emitted (the signal function is called). The signal method returns after all connected slots have been called. In a multi-threaded case, it depends on whether the sender and receiver are associated with the same thread.

    Have a look at for more details.

  • please explained your problem in detail.

  • miroslav is right, but I guess the more correct answer is: it depends on what connection flag you used when you connected the signal and the slot. The default flag will result in different behaviour in threaded and non-threaded cases.

Log in to reply