协程间 跨线程通信的一个问题 about tbox HOT 10 CLOSED

1. 是的
2. 是的

处理消息本质上是事件驱动，打印tick本质上是计时器驱动。从设计上应该分成两个独立的线程比较好。

如果确实要放在同一个线程里面，版本2更合适。以计时器驱动，每个tick检查queue，自己控制计时器的频率。但这样需要注意处理消息引入的时间开销能否够满足设计频率的需求。

from tbox.

是不是可以这样. 就是 把 "tb_coroutine_start" 做成 线程安全 的.

线程A想让线程B做某事的时候. 可以用如下代码.

void do_sth(tb_cpointer_t priv)
{
    //.....
}


void A()
{
    tb_coroutine_start(B.scheduler,dosth,nil,0);
}

from tbox.

不是非常清楚你的需求和业务，但从我看到的信息来看，推荐使用线程池来解决

from tbox.

如果你的处理msg不是非常耗时，很快就能处理完，那么，在一个线程的两个协程里面处理就行了，不必要开两线程，然后用协程锁coroutine_lock或者协程channel做queue通信：

void main()
{
    tb_coroutine_start(scheduler, recv_tcp_data,tb_null,0);  
    tb_coroutine_start(scheduler, do_handle_msg,tb_null,0);
    tb_coroutine_start(scheduler, do_show_tick,tb_null,0);
    tb_co_scheduler_loop(scheduler, , tb_true);
}

void a_recv_tcp_data(tb_cpointer_t priv)
{
    while(1){
        data = recv_from_tcp();
        msg = decode(data);

        coroutine_channel_send(channel, msg); 
    }

}

void do_show_tick(tb_cpointer_t priv)
{
    while(1)
    {
        tb_trace_i("tick...");
        tb_sleep(10*1000); // 协程内的sleep就是 tb_coroutine_sleep
    }

}

void do_handle_msg(tb_cpointer_t priv)
{
    while(msg = coroutine_channel_recv(channel)){
         // 处理msg
    }
}

channel_send/recv如果channel满了send不了，或者空了recv不到，就会自动挂起当前协程，切到其他协程去执行io操作，如果其他协程也没事情可做，就会切到调度器内置的协程，去epoll wait挂起等待，知道有io事件触发。

from tbox.

看你的代码，如果一个线程，就开了一个协程去收数据，或者去处理msg，这种就没必要用协程了，还不如全部线程操作了

from tbox.

如果你处理msg比较耗时，而且就一个recv loop在收数据 然后处理io消息，就没必要协程了，直接一个线程用于recv loop，收到的数据直接放入线程池处理，然后queue用线程lock下就行了。。

from tbox.

你可以参考下https://github.com/tboox/tbox/blob/master/src/demo/coroutine/spider.c 这个爬虫demo，里面对协程，线程池，生产消费，stream io，数据处理，线程同步等有涉及，算是比较综合的一个例子了

from tbox.

又思考了下, 我的程序换模型了. 不过感觉协程跨线程通信, tbox 可以提供更好的支持. 不能因为一个协程等其它线程数据, 而卡住整个调度器.

from tbox.

我觉得并没有什么问题，之前描述的已经比较清楚了，在协程里面 可以跟其他线程 通过lock 同步数据，这并不会导致 卡住问题，在协程里面 本身就不建议 调用线程Wait去挂起，上面我也贴了代码，可以使用两个协程 + channel的方式来解决，而不是 协程 + 线程。。

这跟tbox本身没啥关系，像demo里面提供的spider，以及http server里面的例子，都有通过 协程+多线程+多个调度器 利用多核处理的实例，而且我这边自己各种应用场景中，多线程+协程的场景 也普遍再用，从没遇到你这 会卡住的问题。。

而且既然你需要协程+线程通信，那么为什么不把需要参与跟协程通信的那部分线程，转换成协程一起参与 同一个调度器 调度，岂不是更好，这么混着用反而无法发挥协程的优势，那还不如直接全用线程好了，如果要利用多核，可以开多个线程+调度器 绑定 对应core，但互相之间保持独立，这样反而更加高效。

from tbox.

我觉得并没有什么问题，之前描述的已经比较清楚了，在协程里面 可以跟其他线程 通过lock 同步数据，这并不会导致 卡住问题，在协程里面 本身就不建议 调用线程Wait去挂起，上面我也贴了代码，可以使用两个协程 + channel的方式来解决，而不是 协程 + 线程。。

这跟tbox本身没啥关系，像demo里面提供的spider，以及http server里面的例子，都有通过 协程+多线程+多个调度器 利用多核处理的实例，而且我这边自己各种应用场景中，多线程+协程的场景 也普遍再用，从没遇到你这 会卡住的问题。。

而且既然你需要协程+线程通信，那么为什么不把需要参与跟协程通信的那部分线程，转换成协程一起参与 同一个调度器 调度，岂不是更好，这么混着用反而无法发挥协程的优势，那还不如直接全用线程好了，如果要利用多核，可以开多个线程+调度器 绑定 对应core，但互相之间保持独立，这样反而更加高效。

使用两个协程 + channel的方式来解决, 前提是 msg处理事件短. 后面综合的例子,我再学习下. 谢谢.

from tbox.