Cleanup and prevent thread starvation while in the read window. #844
Conversation
I agree. Areg asked me to work on this yesterday, and it seems both Lin and I worked on this in parallel. |
|
Was focusing on fixing the main branch this afternoon. We should get together when Kevin is back to talk about the best way, keeping in mind to benefit Kevin's upcoming PR. |
|
What test do we have that run readonly transactions, with a read window active? I believe |
| trx = std::move(queue.front()); | ||
| queue.pop_front(); | ||
| return true; | ||
| } |
There was a problem hiding this comment.
I feel this is more complicate.
There was a problem hiding this comment.
I don't understand what you mean by this.
| bool should_exit() { | ||
| return *received_block_ptr || exiting_read_window || | ||
| fc::time_point::now() >= read_window_deadline; | ||
| return *received_block_ptr || exiting_read_window || fc::time_point::now() >= read_window_deadline; |
There was a problem hiding this comment.
I think the condition in #862 is better and clearly spelled out (num_waiting == max_waiting || fc::time_point::now() >= read_window_deadline || *received_block_ptr). And the order reflects the likelihood of conditions too.
There was a problem hiding this comment.
I don't want to test num_waiting == max_waiting here on purpose.
Resolves #822.
This PR encapsulate wait and lock operations in the ro transaction queue, and makes the tasks wait on a condition variable while the read window is active, and there are transactions either in the queue or being processed.
It addresses the issue of thread starvation described in issue #822.