Btw, if that was the only concern I think you could just accept it, rebasing to master was pretty easy and straightforward and would enable landing some diffs already reducing cycles.

rebase

rebase

rebase

rebase

rebase

In D5092#149343, @jon wrote:

better

In D5091#149340, @jon wrote:

better

In D5090#149337, @jon wrote:

better

This doesn't work when I try to patch on the top of D5123, otherwise, it looks alright.

I cannot patch this diff locally. I fetched tags and pulled changes from the remote. Please, fix this (or maybe I missed something?).

rebase

rebase

rebase

address feedback

Thanks for the review. Addressed feedback.

use &str

use more &str instead of String

Right 😅

remove redundant code

I understand your concerns. The point here is that I wanted to have a possibility to schedule a task and if this task doesn't fail, then schedule a callback that is called only afterward. If you take a look at the implementations, these tasks/callbacks differ so I think that introducing a separate layer of abstraction makes sense.

newline

address feedback - use boost's thread pool

Ok, I see your point. It feels like you think I just never described what was wrong with those tests. I kind of described what was the problem in the description. Before this revision, the integration tests tended to not work because of the reasons I described. This revision eliminated this problem.

In D5072#148855, @tomek wrote:

Is it the case that integration tests are failing now? If this is the case, which diff broke them? We have to make sure that tests pass after every diff.

address feedback

avoid unsafe

update

update

update

update

update

avoid panic

I understand, you're right. The goal was to provide the POC asap so the performance tests would work. I'm going to look into the c++ thread pooling.

fix version

The Worker class is not that well-thought-through and I realize that. The first problem is that there's no limit to schedules, another one is that we don't have that much control over the threads - we join them but in the destructor, and this is basically a singleton with a static instance; that means it's going to be released when the app's about to terminate. We could maybe detach the threads... But all in all, I think that we should think about what is happening here and pursue more control over this "worker" aka "thread manager"/"thread pool".

I see your point. I would go with a follow-up for this as it looks uncertain and it may be quite a lot of work/refactoring.

address comments