Eugene Kabanov

@arnetheduck right now `{.async.}` almost not modifying original procedure declaration, so all the type system works properly and shows proper places for some wrong types, but as soon as we...

With current implementation of timers inside `chronos` this implementation become very ineffective because its going to create a lot of timers while under pressure. So it become not a solution...

Its possible, but in chronos we trying to make generic solution, which can be used not only for request rate-limiting, but also for network traffic shaping.

I'm sorry @jangko, there no reason to make benchmarks on multi-threaded vs single-threaded apps. Could you please try to limit number of processes/threads used by chosen framework?

From my tests on VM with just only 2 processors available, `mofuw` is not so performant, and also it produces more errors, not successful responses: ``` Running 10s test @...

While on the same VM asyncdispatch2 benchmark produces such output: ``` cheatfate@phantom ~/wrk (git)-[master] % ./wrk http://127.0.0.1:8885 Running 10s test @ http://127.0.0.1:8885 2 threads and 10 connections Thread Stats Avg...

@jangko, from what i see `asyncdispatch` and `asyncdispatch2` benchmarks - do not support `pipeline` messages. So why you are testing it?

But you can adjust benchmark source to support pipeline for both `asyncdispatch` and `asyncdispatch2`.

First of all thanks for your work @nitely. Just a remark: For `asyncnet` version you not using procedure `readHeaders()` which internally performs one more allocation for `asyncdispatch2`. Also i'm pretty...

Could you please show me optimized version? because asyncdispatch2 can load all headers in one step too (next step of optimization) and also uses unnecessary `readHeaders()`. I will check file...