那是你这个第三方函数的问题。不关协程的事。你非要每个协程里面运行一个 Scrypt 算法高纳德过来也没办法啊。

【 在 ylh0315 的大作中提到: 】
: 我的一个第三方函数需要6m内存。这是在静态测试时测出来的。
: 用的stackfull。就算自增栈，也迅速占用。
--
FROM 59.60.25.*

是的，如果做协程框架中间件让别人来用，不能限制别人呀。
我只能屈服，搞了一个栈池。只用了2×线程数的栈。（32核32线程，1万协程，1w客户端，64栈）
一个线程池/多协程/栈池的方案。
我只负责调度协程资源，然后调用用户函数，用户函数干了啥我不晓得。
我不会用stackless，只能用stackfull。
人家就是用我的框架，你是啥协程人家不管，能把我函数运行起来就行。
【 在 hgoldfish 的大作中提到: 】
: 那是你这个第三方函数的问题。不关协程的事。你非要每个协程里面运行一个 Scrypt 算法高纳德过来也没办法啊。
:
--
修改:ylh0315 FROM 221.218.61.*
FROM 221.218.61.*

rust1.0之前是实现的stackful的，不知道为啥去掉了，后来才搞的这个async。现在越来越觉得async和非async简直是两个世界  
  
【 在 hgoldfish (老鱼) 的大作中提到: 】
:  对哦。c++ 和 rust 都积重难返。为了兼容以前的代码，所以故意设计成 stackless 语法。不论是性能还是语法美观度都是渣渣。
:  
:  而 go 从头开始设计，把协程作为语言的核心概念，是目前唯一一个这么干的主流语言，也是它能够流行的重要原因。
:  
--
FROM 222.64.175.*

为什么？当然是有原因的咯：

https://stevenbai.top/rust/futures_explained_in_200_lines_of_rust/#%E7%BB%BF%E8%89%B2%E7%BA%BF%E7%A8%8Bgreen-threads


【 在 ensonmj 的大作中提到: 】
: rust1.0之前是实现的stackful的，不知道为啥去掉了，后来才搞的这个async。现在越来越觉得async和非async简直是两个世界  
--
FROM 101.71.38.*

rust不比go老多少吧，怎么就积重难返了？


【 在 hgoldfish 的大作中提到: 】
: 对哦。c++ 和 rust 都积重难返。为了兼容以前的代码，所以故意设计成 stackless 语法。不论是性能还是语法美观度都是渣渣。
: 而 go 从头开始设计，把协程作为语言的核心概念，是目前唯一一个这么干的主流语言，也是它能够流行的重要原因。
--
FROM 202.99.52.*