zoukankan      html  css  js  c++  java
  • Qt信号槽的一些事 Qt::带返回值的信号发射方式

    一般来说,我们发出信号使用emit这个关键字来操作,但是会发现,emit并不算一个调用,所以它没有返回值。那么如果我们发出这个信号想获取一个返回值怎么办呢?

    两个办法:1.通过出参形式返回,引用或者指针的方式带回;比如emit sig(int& i)或者emit sig(void* pointer),但是这个方法有一个弊端,稍后介绍第二种方式会提醒。

    2.通过qt自带的invoke机制调用:参考文档对QMetaObject::invokeMethod的说明:Invokes the member (a signal or a slot name) on the object obj.也就是说回调是可以回调信号或者槽的。一般来说,我们使用invokeMethod是在子线程需要调度UI操作的时候(已经有很多文章详细说明了使用方式,不再赘述),因为UI操作只能在主线程中使用(否则会出现未定义错误),通过这种回调方式,让要操作的事件回到主线程时间片的时候再来执行。大部分情况下,我们把UI操作封装在一个槽里,用回调方式来调度。同样信号也可以用这种方式,但是有几点需要注意的是,1.调用回调的连接方式:如果信号和连接槽在一个线程内,那么必须用Qt::DirectConnection或者Qt::AutoConnection,这样的话,保证信号回调后,线程会等待信号连接槽执行完毕,才可能取到我们需要的返回值;如果使用了Qt::QueuedConnection,那么信号只是负责把事件交给事件队列,然后马上做出返回,这样,是否有返回值就无法确定了(这也就是第一个方法的弊端,因为信号发射是根据信号和槽各自的线程情况来选择的连接方式).如果信号和槽在两个线程中,那么首先肯定不能使用Qt::DirectConnection,除非你很清楚连接槽的动作是否保证了线程安全。但根据第一条的说明,也不能使用Qt::QueuedConnection。不过还好qt提供了一个额外的连接方式就是Qt::BlockingQueuedConnection,这个连接方式会阻塞住发射信号的线程一直等到队列连接槽返回后,才会恢复阻塞,这样就可以保证我们能拿到真正的返回值。(但是使用这种方式需要你清楚的知道,发射线程是否允许阻塞和连接槽是否对这个阻塞线程有什么特别的操作,一般来说,如果这个线程并不是由你自己控制的话,不要随便尝试去阻塞别人的线程,因为你并不清楚别人线程的执行逻辑)

    调用方式大致代码如下bool bReturn; QMetaObject::invokeMethod(&object, "sig", Qt::DirectConnection/*Qt::QueuedConnection*/, Q_RETURN_ARG(bool, bReturn), Q_ARG(int, i));

    https://github.com/KaiMingPrince
     

    注:此文是站在Qt5的角度说的,对于Qt4部分是不适用的。

    1.先说Qt信号槽的几种连接方式和执行方式。

    1)Qt信号槽给出了五种连接方式:

    Qt::AutoConnection 0 自动连接:默认的方式。信号发出的线程和糟的对象在一个线程的时候相当于:DirectConnection, 如果是在不同线程,则相当于QueuedConnection
    Qt::DirectConnection 1 直接连接:相当于直接调用槽函数,但是当信号发出的线程和槽的对象不再一个线程的时候,则槽函数是在发出的信号中执行的。
    Qt::QueuedConnection 2 队列连接:内部通过postEvent实现的。不是实时调用的,槽函数永远在槽函数对象所在的线程中执行。如果信号参数是引用类型,则会另外复制一份的。线程安全的。
    Qt::BlockingQueuedConnection 3 阻塞连接:此连接方式只能用于信号发出的线程(一般是先好对象的线程) 和 槽函数的对象不再一个线程中才能用。通过信号量+postEvent实现的。不是实时调用的,槽函数永远在槽函数对象所在的线程中执行。但是发出信号后,当前线程会阻塞,等待槽函数执行完毕后才继续执行。
    Qt::UniqueConnection 0x80 防止重复连接。如果当前信号和槽已经连接过了,就不再连接了。

    2)信号槽的调用方式和线程:

    UniqueConnection 模式:严格说不算连接方式,方式就是4中,此只是一个附加的参数。不讨论。

    AutoConnection 模式:这个模式是默认的,但其可以看作是DirectConnection和QueuedConnection的自动选择,直接分析那两种也就行了。

    发出信号,调用槽的方式也可以简单的分为两种:同步调用和异步调用

    同步调用:发出信号后,当前线程等待槽函数执行完毕后才继续执行。

    异步调用:发出信号后,立即执行剩下逻辑,不关心槽函数什么时候执行。

    所以有下表:

    线程/模式 DirectConnection QueuedConnection BlockingQueuedConnection
    相同线程 直接调用,同步调用。 通过事件进行队列调用。异步调用. 不可用
    不同线程 直接调用。同步调用。槽函数在发出信号的线程执行。有线程安全隐患。 通过事件进行队列调用。异步调用.槽函数在对象所在的线程执行。线程安全。 通过事件进行阻塞调用。同步调用。槽函数在对象所在的线程执行。线程安全。
    Qt事件循环依赖 直接调用,不依赖Qt事件循环 通过事件进行队列调用。依赖,槽函数所在对象的线程必须启用Qt事件循环 通过事件进行队列调用,用信号量实现阻塞。依赖,槽函数所在对象的线程必须启用Qt事件循环

     

    2.Qt信号连接多个槽,调用顺序。

    先说基本原则:

    槽函数开始调用的顺序和连接的顺序是一致的。

    但是,上面也说了,有同步调用和异步调用。

    对于同步调用,你观察的结果和基本原则一样。

    但是对于异步调用,可能你最先连接的它,但是可能其他都执行完毕了,但是其还没执行。是因为对于异步调用:是开始调用的时候,生成一个需要调用这个函数的事件,然后放到事件队列里。然后立即返回,去执行调用其他槽函数或者槽函数都执行了,不关心槽函数的执行状态的。等到事件队列里任务轮到此事件再去调用。

    3.信号的返回值。

    大都说Qt信号槽不能使用返回值。其实不不准确的,Qt5中,信号槽是有返回值的。只是Qt的一个信号可以连接多个槽,还有同步调用和异步调用的问题,没发支持的很好,所以,返回值虽有,但只是鸡肋。

    先说下返回值的规则把:

    • 同步调用才有返回值,异步调用的返回值永远为返回值类型默认构造函数出来的。
    • 连接的多个槽都返回值,那么结果是最后调用(连接)的那个。

    也就是说对于QueuedConnection连接的信号槽,永远只是返回返回类型的默认构造函数的。对于AutoConnection连接的,如果发出信号的线程和槽函数线程不同亦然。

    测试小例子地址:https://github.com/dushibaiyu/DsbyLiteExample/tree/master/QtSignalsSlotTest

    4.信号参数的安全问题:

    因为一个信号可以连接多个槽函数,如果参数是T * 或者是T &话会不会第一个槽函数改变参数的值,然后第二此调用的参数就已经不是信号发出的值?

    1)对于T &: 在同步调用中则是变化的,不可用于异步,不可跨线程。所以BlockingQueuedConnection方式的同步也不行。(T& 不可用在队列调用(QueuedConnection)和阻塞调用(BlockingQueuedConnection)中。只能使用const T &。)

    因为同步调用,你可以理解成直接调用,那么连接多个槽函数就相当于直接连续调用多个函数。类似于:

    // 函数原型都是:void  (int &a )
    int a;
    fun1(a);
    fun2(a)
    ·····
    
    // 函数原型都是:void  (int * a )
    int a;
    pfun1(&a);
    pfun2(&a)
    ·····
    

      

    这样,当第一个函数执行改变参数值之后,其后的函数调用都要受影响。

    2) 对于T *,最好不要同时连接多个槽。

    对于同步调用:是一个接着一个调用的,执行顺序类似上面,所以值也是每次调用也会变化的。

    对于异步调用:其内容确实不确定的,因为异步调用的时间是不可控的。如果还有跨线程相关,则还有线程安全问题。

    5.信号槽性能损失:

    注:仅仅代码层进行的理论分析,非实际测试,不严谨,不权威。

    关于信号槽(很多吐槽Qt就是说的这个):

    (1)Qt4语法的,都说是匹配字符串,其实只是链接信号槽的用的匹配字符串 的方法,通过字符串找到信号和槽在QMeatObject里存的索引位置int类型,还有槽函数的索引,然后调用的时候通过索引号用switch去区分的 发射的那个函数,然后取出对应的链接槽的list,循环检测槽函数的参数是否匹配,然后调用槽函数。。这个链接时会耗时查找,但是你能有多少信号?这个链 接也耗时不多,调用的时候耗时主要就是在参数匹配上了。

    (2)Qt5 语法的,Qt5 的槽函数链接和执行是基于模板实现的,函数对象。信号和槽的参数问题是编译时检查的,执行效率更高,但是编译就慢点了。链接时也是通过信号的地址找到其的 信号索引,至于槽函数直接是生成一个函数对象的,然后调用的时候也是先switch找到发射的信号,取出list,然后逐个调用其储存的函数对象,所以对 于Qt5 语法的信号槽,调用性能损失几乎可以说无的。

    (3)链接的信号槽的时候,Qt::UniqueConnection的链接方式会对已经链接过的此先好的槽函数进行遍历,会有链接时的损失。其他链接的损失就在上面说过了。
    (3)在信号槽调用的时候,还有一些链接方式和线程的判断和为了安全问题的锁操作。关于这个就还涉及到调用槽函数的线程问题。

    对于同线程直接调用,较函数对象直接调用的损失,就只有链接方式和线程的判断的几个if 分支和 锁的操作。
    对于线程间通讯的调用,跨线程。信号槽内部也是通过Qt事件循环机制实现的,跨线程就不是时时调用了,主要是安全了,对于性能有没有损失没法评论的。对于跨线程阻塞的调用,这个也是事件实现,只是但发射信号的线程会阻塞,这个找不到对应的直接调用的比较,也不好说。
    关于信号槽Qt是作何很多方便使用和安全调用,较之函数指针,性能会有损失,但是也没损失多少的。对于函数对象调用,Qt5语法的调用,几乎是不损失什么的。

    注:此文是个人根据文档,源码和自己写小例子测试得出的总结,如有错误请您指出。

  • 相关阅读:
    结构化建模分析
    qemusystemriscv64 machine \?
    git clone commit
    riscv gdb machine mode
    error: src refspec main does not match any.
    riscv ecall
    git windows
    fixedlink
    iperf交叉编译
    每日学习
  • 原文地址:https://www.cnblogs.com/h2zZhou/p/10195464.html
Copyright © 2011-2022 走看看