#42 楼 @kgen 看来科学上网技术博大精深啊 以后可以在大学开个专业了

#38 楼 @kgen 好吧，我一直以为你已经讲厌了。。。

#33 楼 @kgen 随便你讲啥啦

#31 楼 @kgen 哦 那不错 你可以再做个 Topic 啥的。。

#29 楼 @kgen 赞！这次准备带哪个 MM？

#59 楼 @jimrokliu 至少我在本地用 Sinatra 做测试的时候是不发生 Exception 的

#57 楼 @jimrokliu 那你给个 Example？那个 README 所有 Example 我都研究过的，没有符合要求的

#55 楼 @jimrokliu 不是要并发请求啊。。。是真正的无阻塞

好棒～～

#34 楼 @knwang

这个也许对你有帮助： https://github.com/brandonhilkert/sucker_punch

Ruby 中竟然有这么神奇的异步库 了不起啊！是该好好学习源码了

#46 楼 @jjym HEAD 请求当 GET 处理的 但是有时候我们可能只要 POST 或者 PUT 或者 DELETE 请求。。

#43 楼 @zgm 嗯 你太小看 HTTP 请求了 人家功能是很强大的。。

#41 楼 @zgm 那还有 POST 请求呢 HTTPS 请求呢？还是在人家的轮子上改进比较好

#37 楼 @zgm 刚刚看了下 net/http 的源码 感觉把这个改装一下很容易就可以获得一个完整的 nonblocking 的 http 库了。。

#37 楼 @zgm 是滴呀

#34 楼 @knwang 看上去不错的样子嘛

#29 楼 @linjunhalida

恩，跑通了，我做了一个样例，你看看： https://github.com/halida/nonblocking_http

我觉得可以基于这个方法做一个 HTTPRequest 的 gem 了

#29 楼 @linjunhalida 哇 好棒！！谢谢！

#25 楼 @linjunhalida 我们只有一个效率很慢的 delayed job，这是因为数据库本来就要维护。resque 要用到 redis 就需要 ops 做额外工作去维护了呀，工作量变大又不涨工资的事情他们能批准嘛？

#24 楼 @xds2000

你这个需求已经不是应用层的协议了。直接到下面一层 TCP 吧。

好吧。。。大概确实如此。。

#22 楼 @linjunhalida 你是说 resque 那种？我们的 OPS 大概是不会批准的吧。。我们项目里倒是 delayed job，但是我觉得往表里写数据和发送 http 请求相比效率差不多的。。。

#20 楼 @linjunhalida 说得也是。我觉得我这思路其实很接近 UDP 的。。

#15 楼 @xds2000

是 Stream API? https://dev.twitter.com/docs/streaming-apis

这个相当于挂长连接了吧？其实对于 HTTP 而言，一般挂长连接的时候是只收不发的，比如 SSE 就是这样。 如果要做到一直发，就不能用 HTTP 了。。

#17 楼 @linjunhalida 又不是看最新版本的。。这也叫懂？关键是我还不懂硬件，所以对于 Kernel 源码也只是一知半解。。

#9 楼 @linjunhalida

代码长并且复杂不代表效率不高吧。。说不定时间片切换的消耗比 fork 的消耗大。

这个我也没比较过呀。。我觉得我不懂 OS 底层的东西简直和文盲差不多。。

#10 楼 @nouse 嗯。。因为发送的数据并不重要，事实上即使发送不成功也无所谓。正是因为无所谓，所以也不希望损耗过多的性能在站上面。fork 一个 curl 还是 fork 吧。。

#11 楼 @linjunhalida 底层东西我就不懂了呀。。哪个 C 的发送库能够实现这个功能呢？

#9 楼 @linjunhalida 当然没这么简单，很多号称 non-blocking 的 http 发送实际执行的时候还是在明显的 block（最简单的例子就是EM.run），无论 callback 是否为空。我希望的就是真正 non-blocking。

#7 楼 @bhuztez 我大学时候读的 Kernel 源码，感觉 fork 一个进程执行的代码相当长而且复杂。一般感觉只要是 syscall 效率都不会很高。