twosee
twosee
> * libcat 会提供PHP扩展么 这样子workerman可以做驱动适配 Swow就是基于libcat的扩展，只是没有开放事件相关的API（因为是协程风格的，设计理念上不需要引入事件API就能满足所有场景，协程 + 纯同步的API就可以达到异步的性能）。
> ``` > $count = \count($this->_readFds); > if ($count >= 1024) { > echo "Warning: system call select exceeded the maximum number of connections 1024, please install event/libevent extension for...
@lanlin `php -d extension=swow --ri swow` 看看信息，是不是因为你编译的时候没有启用ssl支持？
> ```shell > ./configure --with-openssl-dir=/usr/local/opt/[email protected] > .... > .... > creating libtool > appending configuration tag "CXX" to libtool > configure: patching config.h.in > configure: creating ./config.status > config.status: creating...
> > Swow hook了相关API以后, select的背后其实已经变成了epoll，是没有限制的， > > 经测试存在问题，开启Swow扩展后，stream_select函数没有如期运行 > > TCP工具创建3000个， 但在1000个左右就卡住不动了，建立不起来（workerman与如下单独php示例 都一样） 抱歉，我忘了，由于兼容了C API 的 select实现，仍旧有1024个的最大限制。。。(底层机制是不限制的，但是传参的方式限制了最大个数) 看来有必要提供一套新的事件API，但说实话比起直接用协程同步写法，会低效很多
像是 Swow 写日志 的报错，但信息太少不知道写了什么，讲道理可以安全地忽略。
那有点神奇，但是看不到报了什么，stderr 不可用的时候会出现这个问题。 @dixyes
已知问题，要先 bind 才能设置。并且 Swow 是纯协程的（Swoole 是异步混合），没有缓冲区大小问题， 因此不建议去改这个配置，没必要。 @limingxinleo
建议改成用channel广播，即有一个协程在获取中时，将标志位置为true，如果此时有更多的协程也需要获取，就去创建channel，首个获取协程返回时，如果检查到有其它等待获取的协程（即channel被创建了），就往这个channel里push获取到的对象直到channel没有订阅者。 或者，后来的协程使用yield挂起，并记录到一个队列里，当第一个获取的协程获取完成后，挨个去resume那些等待的协程。 总之，sleep的轮询检查的方式非常低效，而且很不优雅。
> 在框架启动时 ，Di组件 没有在协程环境 Swow下没有非协程环境，主协程和其它手动创建的协程都是平等关系； Swoole下比较麻烦，要么得把启动阶段套在`Co\run()`里，要么如果非协程环境总是第一个去获取对象的，可以通过临时创建一个协程去push的方式广播给其它协程，但无法实现订阅。