make sure rest-client have a timeout which would fire eventually. we don't want to lock a thread in a pool.
So we introduce RestCore::CLIENT to hold the client class to get the corresponding thread pool. We want different thread pools for different clients I assume. By default, we set Client.pool_size to 0 to disable thread pool, so that we could have unlimited concurrency power. Additionally, setting Client.pool_size to a negative value, e.g. -1 would be telling rest-core that do not spawn any thread, just do a blocking call there. For now, our thread pool would always pre-allocate all threads. That is, if we set pool_size to 100, it would then spawn 100 threads upon first call. This might not be desired, but it's much easier to implement as the first version. Also, currently there's no way to shutdown the thread pool, so those threads live in the pool would live forever (until the process is died). This might also not be desired, but much easier to implement. We could also implement trimming in the future. That is, if we're only using a very small number of threads in the pool, we could slowly shut some threads down, and spawn more whenever we really need. Summary, for now: * Client.pool_size = 0 # Spawning a new thread each time. * Client.pool_size = 9 # Use 9 threads totally for this client. * Client.pool_size = -1 # Use no additional thread, doing blocking call. TODO: * Spawning threads on demand instead of spawning all all the time. * Automatically trim the thread pool whenever there are idle threads. * The ability to shutdown the thread pool elegantly. I'll probably take puma's thread pool implementation as a reference. https://github.com/puma/puma/blob/v2.7.1/lib/puma/thread_pool.rb
* rename Future to Promise * rename Proxy to Future * rename Future#on_load to Promise#fulfill * rename Future#on_error to Promise#reject * rename Future#wrap to Promise#gofor we also tried to make eventmachine's timeout more like rest-client in this commit.