c/c++的开发人员是不是越来越少了？

水木社区手机版

主题:c/c++的开发人员是不是越来越少了？
101楼|ylh1969|2021-11-25 17:50:51|展开
等我好好学习下。
我那个功能可能与你说的有所不同。
【在 hgoldfish 的大作中提到: 】
: 哦？用的什么原理吗？
: 我实现的协程 lock, event, condition, semaphore:
: https://github.com/hgoldfish/qtnetworkng/blob/master/src/locks.cpp
: ...................
--
FROM 221.221.53.*
112楼|ylh1969|2021-11-26 20:37:38|展开
我的方案是多线程协程，协程在线程间跳来跳去。
线程也在协程间跳来跳去。
线程池+每连接一个协程。
所以，协程锁非常困难，规定了线程锁不得跨越IO。

【在 hgoldfish 的大作中提到: 】
: 不支持协程在多个线程上执行就行了。
: 你看 nodejs 和 python 都是单线程的。
:
--
FROM 221.221.53.*
114楼|ylh1969|2021-11-26 21:09:56|展开
我不知道。
我这个是交易中间件的服务器框架。
【在 littleSram 的大作中提到: 】
: 这个是不是和goroutine差不多了多对多
--
FROM 221.221.53.*
115楼|ylh1969|2021-11-26 21:13:23|展开
这样的构造，协程锁非常困难。所以，用于客户端间没啥联系的场合，如交易中间件。如果客户端间联系紧密，如游戏，P2P应用等，就不太适合。
【在 littleSram 的大作中提到: 】
: 这个是不是和goroutine差不多了多对多
--
FROM 221.221.53.*
127楼|ylh1969|2021-12-01 11:03:54|展开
刚想起来，有一个signalfd的东西。
可以用这个把事件带到epoll处理，解决多线程协程锁。
【在 hgoldfish 的大作中提到: 】
: 这种方案的话，协程锁的开销比较大。我之前也考虑过这种方案。你前面也说过，可能不太适合有复杂交互的。
: go 语言其实也是你这种方案，所以需要引入 channel 这个东东。使用所谓的 CSP 模型，和所谓的 ACTOR 方案差不多，而不是开销巨大的锁模型。
: 总之我觉得一定要有协程间同步，不然不够用。
: ...................
--
FROM 221.221.50.*
132楼|ylh1969|2021-12-01 11:46:36|展开
牛。
【在 hgoldfish 的大作中提到: 】
: 是的啊。。我就是这么实现的。
:
--
FROM 221.221.50.*