标题 No.33 - 基于 Posix 接口的协程框架
描述
对于大部分应用程序,实际并不关心实际的运行实体是什么。基于linux kernel的线程调度机制相较于协程占用资源多,上下文切换时间长。当前行业内的解决方案主要是语言级别的协程调度方案,典型的如go routine。本课题的目标是基于glibc的posix接口编程,提供用户无感知的协程调度框架,解决提升存量软件性能。
具体包含:
目标一:pthread相关库的协程化,包含线程管理已经基于线程的条件变量,锁等接口。
目标二:基于目标一,实现网络编程相关接口的协程化。
目标三:全量的posix接口协程化配合。
glibc源码:
https://gitee.com/src-openeuler/glibc
难度 高
产出标准
技术要求
Hey @liqingqing_1229, Welcome to openEuler Community.
All of the projects in openEuler Community are maintained by @openeuler-ci-bot.
That means the developers can comment below every pull request or issue to trigger Bot Commands.
Please follow instructions at https://gitee.com/openeuler/community/blob/master/en/sig-infrastructure/command.md to find the details.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。
Hi, @liqingqing, I'm Bin Gao, who inquired about this project through the mail before.
As you explained in the mail, we need to develop a language-level coroutine framework without hurting any current POSIX standards.
To do this, inspired by the existing solutions, I think we have the following aspects to discuss now.
For the above questions, there are several designs and considerations in existing solutions, such as libgo, lthread, and libco. Learned from these libraries, I propose we answer the above question with these techniques.
Our current task is to discuss and determine the architecture and design of this framework. It's important because we should consider the new features to make the future upgrades easy.
What're your opinions? Hope your suggestions.
登录 后才可以发表评论