关于 ruby / rails 的线程模型

inu 的项目中有一个导入功能，将用户从浏览器、del.icio.us 导出的收藏条目导入到 inu 收藏夹中。这个功能推出以来，用户的反响并不好，其主要原因在于：速度慢，考验用户的耐心。

速度慢的问题，根本原因在于 model 层需要做的工作非常多，也是目前不完善的架构以及比较特殊的需求导致的，可以说不能从根本上解决。每次导入一条记录，都需要更新好几个表，本身 ruby 在目前虚拟机下效率并不高，所以导入的速度并不理想。

那么，退而求其次，可以设置一个直观的进度条来告诉用户目前导入的进度，可以在很大程度上缓解用户的焦虑、不信任的心理。

解决方案是确定了，可是问题由此而来：ruby 是单线程的。

严格来说，应该是目前的虚拟机还不支持真正多线程的 ruby 应用。虽然 ruby 中确实有 Thread 类 ，但是查阅相关文档可以知道，这个类是一个伪 Thread，不同于真正的多线程。如果通过 join 将子线程挂到当前的主线程中（某个 mongrel 进程），那么该线程在结束之前会等待所有的子线程结束。通常情况下这种机制可以模拟出和其他语言相类似的线程模型。但是在 rails 中，有新的问题产生：无论是 FastCGI 还是 Mongrel ，都是一个请求独占一个进程，每次请求都会创建新的 Controller 实例，请求结束后该实例销毁。也就是说，在 Controller 内无论是不使用线程、或是把子线程挂到主线程上，在所有操作结束之前，当前进程一直处于 block 状态。

很可怕！

通常用 thread 是在不影响主线程的情况下处理耗时很多的操作。但是这种机制明显不能应付这种需求。一台服务器上 mongrel 数量有限，都被阻塞了，相当于服务器在这段时间内不能接收其他的请求。

那么是否让 thread 单独执行就可以了呢？答案也是否定的。在单独的线程中，Model 类将不再是 Model。其实意思是：线程中的 ActiveRecord 类不再具有标表间关联（目前我测试出来就这么多，可能还会失去更多东西），只是一个普通的实体类。对于这样的导入，无疑就是毁灭性的。

至此，可以确定，这个应用不可避免的要阻塞一个 mongrel 了。那么如果要反应当前导入的进度，就是要发起一个新的请求，查询导入状态。如果这个请求发送到 rails ，意味着用户的导入要占用 2 个 mongrel ，服务器不可能有这么多的资源。

最终我采取了一种折中的方案，导入时创建一个可访问的静态资源，查询进度的功能由这个静态资源来完成，而 web 应用对于静态资源的访问则由 apache 来完成。

至此，问题算是解决了，虽然算不上完美。期望 ruby 的虚拟机能够尽快支持 multi-thread 吧！