the important part of flow control is to accept enough work to keep yourself busy, but not more than you can eventually retire at that rate, and not more than w

the important part of flow control is to accept enough work to keep yourself busy, but not more than you can eventually retire at that rate, and not more than would require holding more intermediate state that you have room for. [edit: those are really two sides of the same coin...ideally you would also come close to saturating some throughput limit (network/disk/memory bandwidth). and even better come close to saturating all of them] if the work includes tasks with variable delay (using the disk, or an external network service), or uses variable amount of compute, then you need to look at creating appropriate adaptation and overall scheduling strategies (i.e. retire older work first) so while having a queue depth of 1 and implementing everything as fully blocking in the naive threading case is maybe a better place to start than having an infinite queue depth in the naive callback implementation....neither one really gets you to where you need to go without further structure. the only real frustration I have with the threaded approach in trying to build the 'right' system is that at some point you have to deal with the system scheduler being largely workload oblivious. once you build you own scheduler, then whether you are assuming synchronous returns from a programming perspective really is a matter of style, and probably involves more language-provided safety and less boilerplate.