js 是单线程的，哪有什么全局锁啊。

【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 比如 全局锁，然后 判断的时候 io 等 协程了。
: 大概这样的代码
--
FROM 124.72.119.*

传统JavaScript等价于隐式协程，阻塞操作实际上并不block本线程

nodejs发家的c10k问题玩的就是无阻塞，就是协程的变体

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 不是不支持协程，，没看我怎么说的，“多用协程解决一切问题“。
: 我比较希望 js 能够隐式地支持协程。。
: c# 为什么选择 async/await 两个关键词，因为 c# 本身是支持线程的，老旧的 c# 程序都会调用 win32api 里面的阻塞 IO API，以及创建线程做并行计算. 为了在阻塞 IO 这一套语义之外并存地支持协程，c# 不得不额外支持 async 函数，显式地告诉程序员，这是个协程操作。
: ...................
--
FROM 27.91.71.*

协程底层就是 promise，只是个语法糖，怎么实现都不会破坏兼容性。

就算真的有问题，协程 IO API 是新的 API，使用这一套 API 的人，自然也应该使用协程兼容的业务锁。

话说，你们是怎么实现业务锁的。

我经常碰到要等用户完成登录才能继续后继调用的逻辑。目前我用协程 Event 很容易。

【 在 chaobill (若我离去,后会无期) 的大作中提到: 】
: 用全局变量做的业务锁， 在协程里被修改使得锁失效
--
修改:hgoldfish FROM 124.72.119.*
FROM 124.72.119.*

比如以前没有strict模式的老版本MySQL嘛哈哈哈哈

【 在 No1 () No1 () 的大作中提到: 】
: js生命力这么强就因为简单又模糊，搞太复杂清晰了反而不行
: 能恒久远的，总是那些简单而暧昧的物种
--
FROM 61.130.134.*

有问题是是 static 这句
单线程 协程模式 http 服务器 。 各协程的数据都存在这个变量里了

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 这句话有问题吧：
: $user=UserModel::Get($id);
: UserModel::get() 如果知道有网络请求，那么，要么写成 promise 异步非阻塞回调，要么在子线程里面处理也是异步阻塞回调，要么协程同步阻塞。无论哪一种情况，对 $user 都得加锁啊。
: ...................
--
FROM 223.198.99.*