龙空技术网

纯C协程框架NtyCo实现与原理

零声教育 375

前言:

眼前姐妹们对“python主线程子线程”大体比较着重,咱们都需要剖析一些“python主线程子线程”的相关内容。那么小编在网摘上搜集了一些有关“python主线程子线程””的相关文章,希望看官们能喜欢,大家一起来学习一下吧!

前言

  c++两个比较好的协程库libgo和libco,本文用纯c的代码实现一个协程ntyco。

  ntyco源码地址——> gopherWxf/NtyCo——>源码里面有注释,本文是对ntyco的整体做一个梳理。

如果了解过golang的协程的请注意,golang调度器的策略见→深入理解GMP模型,golang的协程与ntyco的协程不一样,ntyco的调度策略是基于 io事件 来做的

 协程用在以下三个方面

1. 文件io的操作2. 网络io的操作3. mysql,redis等第三方库的操作

 本专栏知识点是通过零声教育的线上课学习,进行梳理总结写下文章,对c/c++linux课程感兴趣的读者,可以点击链接C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂详细查看课程的服务。

1. 为什么会有协程,协程解决了什么问题?网络IO优化

  在CS,BS的开发模式下,服务器的吞吐量是一个受关注的参数。吞吐量等于1秒内业务处理的次数,那么这个业务处理其实是由 网络IO时间 + 业务处理时间 组成的。

不同的业务,其业务处理时间是不同的,所以对于业务处理时间的优化,要根据业务场景来优化。而网络IO时间是可以优化的。

  也就是说,如何提升recv和send的性能?现在以Linux服务器百万并发实现为例,使用epoll管理百万长连接,测试IO同步操作与异步操作的性能差别。

 对于响应式服务器来说,所有客户端的操作都是源于这个大循环,对于服务器处理网络IO,handle(sockfd) 的实现有两种方式。第一种,IO同步;第二种,IO异步。

相关视频推荐

陷入回调陷阱,用协程解决异步转同步

协程!协程!协程!给你一个吊打面试官的机会

徒手实现一个协程框架,为你造轮子事业,再添一坑

LinuxC++后台服务器开发架构师免费学习地址

【文章福利】:小编整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面,有需要的可以自行添加哦!(需要视频资料后台私信“1”自取)

IO 同步 操作性能测试

  对于IO 同步操作来说,handle(sockfd) 函数内部实现如下,我们发现IO操作(recv,send)与 epoll_wait 是在同一个处理流程里面的。也就是说,同步:检测IO 与 读写IO 在同一个流程里

Linux服务器百万并发实现就是以同步的方式做的,我们测试出来,每一千个连接,耗时7.5秒左右。

优点:

sockfd 管理方便代码逻辑清晰

缺点:

服务器程序依赖 epoll_wait 的循环,响应速度慢。程序性能差IO 异步 操作性能测试

  对于IO 异步操作来说,handle(sockfd) 函数内部将 sockfd 的操作,push 到线程池中 , 由其他线程进行读写,也就是说,异步:检测IO 与 读写IO 不在同一个流程里

handle(sockfd) 函数将sockfd处理放到另一个线程中处理,使得IO操作(recv,send) 与 epoll_wait 不在一个处理流程里面,实现了解耦,这就叫做IO 异步操作。可以看到下图,每一千个连接耗时2.5秒左右。

优点:

子模块好规划程序性能高

缺点:

正因为子模块好规划,使得模块之间的 sockfd 的管理异常麻烦。每一个子线程都需要管理好 sockfd,避免在 IO 操作的时候,sockfd 出现关闭或其他异常。通俗来讲,需要避免一个fd被多个线程操作的情况发生。协程的诞生

 从上面我们知道了IO同步操作,写代码逻辑清晰,但是效率低;而IO异步操作,fd管理复杂,但是效率高。由此,协程便出现了。

  协程:把两者结合起来,以同步的编程方式,实现异步的性能。即写代码的时候,同步;运行的逻辑,异步。就如下图一样,代码是同步的,而我们通过hook,其运行的时候,就是异步的。

可能有人会说了,上面IO异步操作性能测试明明是用了两个线程,当然比一个线程的同步IO快。首先明确一个概念:同步和异步,一定是描述两者之间的关系

同步:检测IO 与 读写IO 在同一个流程里 异步:检测IO 与 读写IO 不在同一个流程里

 然后再来理解下面的QA问题,注意需要在理解本文协程的时候才能看懂,到时候回过头再看即可。

  Q:为什么协程的效率会更高?单线程reactor用的是epoll_wait, 协程调度也是epoll_wait,从整体上来看不是一样吗?

  A:在没有加入业务解析的情况下,协程性能与单线程reactor是差不多的 ,但是编程会容易很多。首先,用协程业务代码会比较简单,一个协程对应一个fd,业务逻辑都在协程内部;而reactor提供的recv_cb和send_cb是所有业务流程的。

Q:有了业务解析,效率不也一样吗?

  A:业务部分,比如数据库操作的,是比较耗时的阻塞IO,而协程可以通过hook,把recv和send变成异步,把数据库IO阻塞的时间,切换到别的协程上运行,所有阻塞等待的地方,都会引起切换。而同步reactor在业务部分数据库IO就只能干等着。

 Q:为什么会有协程,协程解决了什么问题?

  A:IO同步操作,写代码逻辑清晰,但是效率低;而IO异步操作,fd管理复杂,但是效率高。协程解决了IO同步效率低,IO异步fd管理发杂的问题,协程结合两者的优点,实现了以同步的编程方式,实现异步的性能

2. 原语yield()

  先来理解yield的含义,让出,将当前的执行流程让出,让出给调度器。

那么什么时候需要yield让出呢?很明显在recv之前,send之前,也就是在io之前,因为我们不知道io是否准备就绪了,所以我们先将fd加入epoll中,然后yield让出,将执行流程给调度器运行。

schedule

  schedule调度器做什么事情呢?调度器就是io检测,调度器就是不断的调用epoll_wait,来检测哪些fd准备就绪了,然后就恢复相应fd的执行流程执行现场。注意schedule不是原语,schedule是调度器。

resume()

  从上面我们得知恢复是被schedule恢复的,那么现在恢复到了原来流程的哪里呢?其实是恢复到了yield的下一条代码处。通常下面的代码都会将fd从epoll中移除,然后执行recv或send操作,因为一旦被resume,就说明肯定是准备就绪的。

代码+图 进行理解

  那么如何以同步的编程方式来实现异步的性能呢?我们是否可以包装一层recv(不包装用hook也可以,后面再写hook),在调用recv之前(假设现在的流程为A),将fd加入epoll中,然后将执行流程让出切换给一个调度器(假设调度器的流程为schedule),调度器里面执行epoll_wait,由调度器选择接下来恢复执行哪个流程(这个流程一定是就绪的,因为是从epoll_wait中返回的),可能会恢复到流程B中,那么流程B先将自己的事件从epoll中摘除EPOLL_CTL_DEL,然后就可以执行recv了。我们发现检测IO 与 读写IO 不在同一个流程里,实现了异步,而我们代码看起来却是同步的。

我们从中发现两个原语操作,让出yield恢复resume

如何实现yield和resumeyield:从io操作流程切换到调度器流程(让出)resume:从调度器流程切换到io操作流程(恢复)

  到现在为止应该能理解yield和resume的意思了,但是对于初学者来说,肯定会有疑问,这个切换怎么实现?

如何实现yield和resume:

setjmp/longjmpucontext用汇编代码自己实现切换

本文采用汇编代码实现切换_switch()。

yield=_switch(A,B)resume=_switch(B,A)

//new_ctx[%rdi]:即将运行协程的上下文寄存器列表; cur_ctx[%rsi]:正在运行协程的上下文寄存器列表int _switch(nty_cpu_ctx *new_ctx, nty_cpu_ctx *cur_ctx);// yield让出void nty_coroutine_yield(nty_coroutine *co) {    _switch(&co->sched->ctx, &co->ctx);}// resume协程恢复执行int nty_coroutine_resume(nty_coroutine *co) {	//...    nty_schedule * sched = nty_coroutine_get_sched();    sched->curr_thread = co;    _switch(&co->ctx, &co->sched->ctx);    //...}

 如何从一个协程切换到另一个协程呢?我们只需要将当前协程的上下文从寄存器组中保存下来;将下一个要运行的协程的上下文放到寄存器组上去,即可实现协程的切换。

3. 切换寄存器介绍

下面介绍的都是x86_64的寄存器。

%rdi,%rsi,%rdx,%rcx,%r8,%r9 用作函数参数,依次对应第1参数,第2参数…(这里我们只需关注%rdi和%rsi)%rbx,%rbp,%r12,%r13,%14,%15 用作数据存储,遵循被调用者使用规则,简单说就是随便用,调用子函数之前要备份它,以防他被修改new_ctx是一个指针,指向一块内存,它现在存在%rid里面,同理cur_ctx存在%rsi里面%rsp代表栈顶,%rbp代表栈底,%eip代表cpu下一条待取指令的地址(这也就是为什么resume之后会接着运行代码流程的原因)

//new_ctx[%rdi]:即将运行协程的上下文寄存器列表; cur_ctx[%rsi]:正在运行协程的上下文寄存器列表int _switch(nty_cpu_ctx *new_ctx, nty_cpu_ctx *cur_ctx);
汇编实现切换
//寄存器 cpu上下文typedef struct _nty_cpu_ctx {    void *rsp;//栈顶    void *rbp;//栈底    void *eip;//CPU通过EIP寄存器读取即将要执行的指令    void *edi;    void *esi;    void *rbx;    void *r1;    void *r2;    void *r3;    void *r4;    void *r5;} nty_cpu_ctx;//new_ctx[%rdi]:即将运行协程的上下文寄存器列表; cur_ctx[%rsi]:正在运行协程的上下文寄存器列表int _switch(nty_cpu_ctx *new_ctx, nty_cpu_ctx *cur_ctx);//默认x86_64__asm__("   .text               \n""   .p2align 4,,15      \n"".globl _switch                                          \n"".globl __switch                                         \n""_switch:                                                \n""__switch:                                               \n""       movq %rsp, 0(%rsi)      # save stack_pointer     \n""       movq %rbp, 8(%rsi)      # save frame_pointer     \n""       movq (%rsp), %rax       # save insn_pointer      \n""       movq %rax, 16(%rsi)     # save eip               \n""       movq %rbx, 24(%rsi)     # save rbx,r12-r15       \n""       movq %r12, 32(%rsi)                              \n""       movq %r13, 40(%rsi)                              \n""       movq %r14, 48(%rsi)                              \n""       movq %r15, 56(%rsi)                              \n""       movq 56(%rdi), %r15                              \n""       movq 48(%rdi), %r14                              \n""       movq 40(%rdi), %r13                              \n""       movq 32(%rdi), %r12                              \n""       movq 24(%rdi), %rbx     # restore rbx,r12-r15    \n""       movq 8(%rdi), %rbp      # restore frame_pointer  \n""       movq 0(%rdi), %rsp      # restore stack_pointer  \n""       movq 16(%rdi), %rax     # restore insn_pointer   \n""       movq %rax, (%rsp)       # restore eip            \n""       ret                     # 出栈,回到栈指针,执行eip指向的指令。\n");

  上下文切换,就是将 CPU 的寄存器暂时保存,再将即将运行的协程的上下文寄存器,分别mov 到相对应的寄存器上。此时上下文完成切换。

4. 协程的运行流程协程如何使用,协程的api

  在网络IO编程的时候,如果每次accept返回的时候,为新来的fd单独分配一个线程,这一个fd对应一个线程,就不会存在多个线程共用一个fd的问题了,虽然这样代码逻辑清晰易读,但是这是无稽之谈,线程创建与线程调度的代价是很大的

但是如果把线程换成协程,线程API的思维来使用协程,那不久可行了吗?

NtyCo封装了两类接口

一类是协程本身的api

//创建协程int nty_coroutine_create(nty_coroutine **new_co, proc_coroutine func, void *arg);//调度器运行void nty_schedule_run(void);

一类是posix api的异步封装协程api

//POSIX 异步封装 APIint nty_socket(int domain, int type, int protocol);int nty_accept(int fd, struct sockaddr *addr, socklen_t *len);ssize_t nty_recv(int fd, void *buf, size_t len, int flags);ssize_t nty_send(int fd, const void *buf, size_t len, int flags);int nty_close(int fd);int nty_connect(int fd, struct sockaddr *name, socklen_t len);ssize_t nty_recvfrom(int fd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen);ssize_t nty_sendto(int fd, const void *buf, size_t len, int flags, const struct sockaddr *dest_addr, socklen_t addrlen);
协程工作流程创建协程

创建协程的时候,进行了如何的工作?

int nty_coroutine_create(nty_coroutine **new_co, proc_coroutine func, void *arg);
nty_coroutine **new_co :需要传入空的协程的对象,这个对象是由内部创建的,并且在函数返回的时候,会返回一个内部创建的协程对象。proc_coroutine func :协程的子过程。当协程被调度的时候,就会执行该 函数。void *arg :需要传入到新协程子过程中的参数。

协程不存在亲属关系,都是一致的调度关系,接受调度器的调度。调用 create API就会创建一个新协程,新协程就会加入到调度器的就绪队列中。

回调协程的子过程

  在 create 协程后,何时回调子过程?何种方式回调子过程?我们知道CPU的EIP寄存器就是存储cpu下一条指令的地址,我们可以把回调函数的地址存储到 EIP 中。这样在resume之后,就会执行协程的子过程了。

// eip 执行入口static void _exec(void *lt) {    nty_coroutine *co = (nty_coroutine *) lt;    co->func(co->arg);}// 初始化协程栈static void nty_coroutine_init(nty_coroutine *co) {    void **stack = (void **) (co->stack + co->stack_size);    stack[-3] = NULL;    stack[-2] = (void *) co;//设置参数    co->ctx.rsp = (void *) stack - (4 * sizeof(void *));    co->ctx.rbp = (void *) stack - (3 * sizeof(void *));    co->ctx.eip = (void *) _exec;//设置回调函数入口    co->status = BIT(NTY_COROUTINE_STATUS_READY);}
协程封装posix api异步原理

  在 send 与 recv 调用的时候,如何实现异步操作的?先来看一下一段代码:

 在进行 IO 操作(recv,send)之前,先执行了 epoll_ctl 的 del 操作,将相应的 sockfd 从 epfd中删除掉,在执行完 IO 操作(recv,send)再进行 epoll_ctl 的 add 的动作。这段代码看起来似乎好像没有什么作用。

  如果是在多个上下文中,这样的做法就很有意义了。能够保证 sockfd 只在一个上下文中能够操作 IO 的。不会出现在多个上下文同时对一个 IO 进行操作的。协程的 IO 异步操作正式是采用此模式进行的。

详细说明见目录中2.原语->代码+图 进行理解

// 创建协程recv接口ssize_t nty_recv(int fd, void *buf, size_t len, int flags) {    struct epoll_event ev;    ev.events = POLLIN | POLLERR | POLLHUP;    ev.data.fd = fd;    //加入epoll,然后yield    nty_epoll_inner(&ev, 1, 1);    //resume    ssize_t ret = recv(fd, buf, len, flags);    return ret;}// 加入epoll,更改状态,加入wait集合,然后yield与resumestatic int nty_epoll_inner(struct epoll_event *ev, int ev_num, int timeout) {    nty_schedule * sched = nty_coroutine_get_sched();    nty_coroutine *co = sched->curr_thread;    int i;    for (i = 0; i < ev_num; i++) {        epoll_ctl(sched->epfd, EPOLL_CTL_ADD, ev->data.fd, ev);        co->events = ev->events;        //加入wait集合,添加wait状态        nty_schedule_sched_wait(co, ev->data.fd, ev->events, timeout);    }    //yield    nty_coroutine_yield(co);    for (i = 0; i < ev_num; i++) {        epoll_ctl(sched->epfd, EPOLL_CTL_DEL, ev->data.fd, ev);        //移除wait集合,移除wait状态        nty_schedule_desched_wait(ev->data.fd);    }    return ev_num;} 

一个简单的使用案例

可以看到,我们编写代码只需以同步的编程方式,就能实现异步的性能了。

#include "nty_coroutine.h"#include <arpa/inet.h>void server_reader(void *arg) {    int fd = *(int *) arg;    ssize_t ret;    struct pollfd fds;    fds.fd = fd;    fds.events = POLLIN;    while (1) {        char buf[1024] = {0};        ret = nty_recv(fd, buf, 1024, 0);        if (ret > 0) {            nty_send(fd, buf, strlen(buf), 0);        }        else if (ret == 0) {            nty_close(fd);            break;        }    }}void server(void *arg) {    unsigned short port = *(unsigned short *) arg;    int fd = nty_socket(AF_INET, SOCK_STREAM, 0);    if (fd < 0) return;        struct sockaddr_in local, remote;    local.sin_family = AF_INET;    local.sin_port = htons(port);    local.sin_addr.s_addr = INADDR_ANY;    bind(fd, (struct sockaddr *) &local, sizeof(struct sockaddr_in));    listen(fd, 128);        while (1) {        socklen_t len = sizeof(struct sockaddr_in);        int cli_fd = nty_accept(fd, (struct sockaddr *) &remote, &len);        printf("new client comming\n");        nty_coroutine *read_co;        nty_coroutine_create(&read_co, server_reader, &cli_fd);    }}int main(int argc, char *argv[]) {    nty_coroutine *co = NULL;    unsigned short port = 8080;    nty_coroutine_create(&co, server, &port);    nty_schedule_run(); //run    return 0;}
5. 协程 与 调度器 结构体定义协程定义

  一个协程会有哪些状态呢?

如果协程sleep了,那么就是睡眠状态,如果协程刚创建出来,那它肯定是就绪状态,如果协程在等待数据的到来,那就是等待状态。这里这里定义协程的三个运行状态{就绪,睡眠,等待}。

新创建的协程,加入就绪集合等待调度io未就绪的协程,加入等待集合等待epoll_wait有sleep操作的协程,加入睡眠集合就绪集合没有设置优先级,所以在就绪集合里面的协程优先级一样,那么就可以用队列来存储,先进先出等待集合就是等待IO准备就绪,这个等待IO是有时间长短的,这里用红黑树来存储睡眠集合需要按照睡眠时间的长短进行唤醒,所以也用红黑树存储,key为睡眠时长

我们描述了每一个协程有自己的上下文环境,需要保存 CPU 的寄存器 ctx;需要有子过程的回调函数 func;需要有子过程回调函数的参数 arg;需要定义自己的栈空stack;需要有自己栈空间的大小 stack_size;需要定义协程的创建时间birth;需要定义协程当前的运行状态 status;需要定当前运行状态的结点(ready_next, wait_node, sleep_node);需要定义协程 id;需要定义调度器的全局对象 sched。

typedef struct _nty_coroutine {    //cpu ctx    nty_cpu_ctx ctx;    // func    proc_coroutine func;    void *arg;    // create time    uint64_t birth;    //stack    void *stack;    size_t stack_size;    size_t last_stack_size;    //status    nty_coroutine_status status;    //root    nty_schedule *sched;    //co id    uint64_t id;    //fd event    int fd;    uint16_t events;    //sleep time    uint64_t sleep_usecs;    //set    RB_ENTRY(_nty_coroutine) sleep_node;    RB_ENTRY(_nty_coroutine) wait_node;    TAILQ_ENTRY(_nty_coroutine) ready_node;} nty_coroutine;
调度器定义

  每个协程所需要使用的,而且不同的,就是协程的属性,那么每个协程所需要的,且相同的,就是调度器的属性。用来管理所有协程的属性,作为调度器的属性。调度器的属性,需要有保存 CPU 的寄存器上下文 ctx,可以从协程运行状态yield 到调度器运行的。从协程到调度器用 yield,从调度器到协程用 resume。

typedef struct _nty_schedule {    // create time    uint64_t birth;    //cpu ctx    nty_cpu_ctx ctx;    //stack_size    size_t stack_size;    //coroutine num    int spawned_coroutines;    //default_timeout    uint64_t default_timeout;    //当前调度的协程    struct _nty_coroutine *curr_thread;    //页大小    int page_size;    //epoll fd    int epfd;    //线程通知相关,暂未实现    int eventfd;    //events    struct epoll_event eventlist[NTY_CO_MAX_EVENTS];    int num_new_events;    //set    nty_coroutine_queue ready;    nty_coroutine_rbtree_sleep sleeping;    nty_coroutine_rbtree_wait waiting;} nty_schedule;
6. 调度的策略

  调度器的实现,有两种方案,一种是生产者消费者模式,另一种多状态运行。

生产者消费者模式

逻辑代码如下

多状态运行

逻辑代码如下

7. 协程api 与 hook需要封装为异步的posix api分析

  所有对io的操作,我们都需要取重新封装一遍。为什么不能用posix api,而是我们需要再去封装一次呢?比如我们调用recv的时候,如果我们调用系统的,那么这个fd怎么yield到调度器上呢,所以我们需要在posix api的基础上封装,当然有些接口需要封装,有些不需要。

就像下面的伪代码一样,从同步的recv变成异步的ney_recv

//伪代码ney_recv(){	epoll add fd;	yield();	epoll del fd;	recv(fd);}

站在同步封装成异步的角度,如果不需要判断io是否就绪的这些api,则不需要封装为异步的。

需要封装的api,这些api在实现的时候,皆采用上面伪代码的策略

1. accept()2. connect()3. recv()4. read()5. send()6. write()7. recvfrom()8. sendto()

不需要封装的api,这些api因为不会引起阻塞,所以不用封装。

socket()listen()close()fcntl()setsockopt()getsockopt()
hook

  我们有两种策略封装上面的api,第一种就是定义Nty_XXX(),框架独立定义一套标准接口出来。但是这种方法,如果跟mysql,redis建立连接,但是不去修改它们提供的客户端源码开发包的时候,就会发现连不上去,因为其源码用的是posix api,recv和send。而协程用的是nty_recv()和nty_send()。两者之间没有关联。

第二种就是使用hook,做成跟系统调用,跟posix api一样的接口,那么一样的接口就会引起冲突。这个冲突我们就使用hook来解决。

  hook提供了两个接口;1. dlsym()是针对系统的,系统原始的api。2. dlopen()是针对第三方的库。

 我们现在使用mysql的包去连接mysql来做hook演示,可以看到我们将系统调用的api截获了。对应下面的代码,就是这个意思。

原来的系统调用,被hook后,都变成了xxx_f , 所以我们就可以使用原来的名字,比如read,connect。而mysql包里面走的read,connect这些函数,就变成我们写的函数了,如果我们协程提供的api使用hook的做法,那么mysql,redis这类静态库,动态库的read,write都不用修改,使用了hook,就都会走我们定义的函数。

简单来说,原来的系统调用connect,被改名为connect_f , 所以原来的名字connect就空出来了,交由我们用户实现。而像mysql-dev源码里面用的都是connect,所以就会走我们用户写的函数了。

connect_f = dlsym(RTLD_NEXT, "connect");

#define _GNU_SOURCE#include <stdio.h>#include <unistd.h>#include <dlfcn.h>#include<mysql/mysql.h>//// Created by 68725 on 2022/7/17.//typedef int (*connect_t)(int, struct sockaddr *, socklen_t);connect_t connect_f;typedef ssize_t (*recv_t)(int, void *buf, size_t, int);recv_t recv_f;typedef ssize_t (*send_t)(int, const void *buf, size_t, int);send_t send_f;typedef ssize_t (*read_t)(int, void *buf, size_t);read_t read_f;typedef ssize_t (*write_t)(int, const void *buf, size_t);write_t write_f;int connect(int fd, struct sockaddr *name, socklen_t len) {    printf("in connect\n");    return connect_f(fd, name, len);}ssize_t recv(int fd, void *buf, size_t len, int flags) {    printf("in recv\n");    return recv_f(fd, buf, len, flags);}ssize_t send(int fd, const void *buf, size_t len, int flags) {    printf("in send\n");    return send_f(fd, buf, len, flags);}ssize_t read(int fd, void *buf, size_t len) {    printf("in read\n");    return read_f(fd, buf, len);}ssize_t write(int fd, const void *buf, size_t len) {    printf("in write\n");    return write_f(fd, buf, len);}static int init_hook() {    connect_f = dlsym(RTLD_NEXT, "connect");    recv_f = dlsym(RTLD_NEXT, "recv");    send_f = dlsym(RTLD_NEXT, "send");    read_f = dlsym(RTLD_NEXT, "read");    write_f = dlsym(RTLD_NEXT, "write");}void main() {    init_hook();    MYSQL *m_mysql = mysql_init(NULL);    if (!m_mysql) {        printf("mysql_init failed\n");        return;    }    if (!mysql_real_connect(m_mysql, "192.168.109.1", "root", "123456", "cdb", 3306, NULL, 0)) {        printf("mysql_real_connect failed\n");        return;    }    else {        printf("mysql_real_connect success\n");    }}//gcc -o hook hook.c -lmysqlclient -I /usr/include/mysql/ -ldl

如果我们的协程ntyco要和mysql做在一起,我们在不修改mysql-dev的前提下,只要把下面的接口做成hook即可

1. accept()2. connect()3. recv()4. read()5. send()6. write()7. recvfrom()8. sendto()
8. 多核模式

解决协程多核的问题有两种方式,多线程/多进程 与 CPU核心做亲和性。

多进程(实现起来容易,对协程代码本身不用去改)多线程(复杂,需要对调度器进行加锁)

那么做多线程对调度器进行加锁,锁放在哪呢?锁放在调度器结构体里面,因为调度器是全局唯一的,那么要锁哪里呢,很明显,<取协程,恢复协程>,这里需要加锁。

9. 协程性能测试

4 台 VMWare 虚拟机

1 台服务器 14G 内存,1 核 CPU 3 台客户端 4G 内存,1 核 CPU

操作系统:ubuntu 18.04.6

服务端测试代码: 服务器端测试代码

客户端测试代码:客户端测试代码

按照每一个连接启动一个协程来测试,每个协程栈4k,测试协程数量100w无异常,并且能够正常收发数据。

原文地址:

标签: #python主线程子线程