-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement wait queue #1061
base: master
Are you sure you want to change the base?
implement wait queue #1061
Conversation
e43b37a
to
8d0b434
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I think that PR is based on wrong assumptions. It doesn't actually use cancellation, it's not ready for extensions in the future, e.g. job workers, RPC futures etc.
@@ -46,7 +46,7 @@ class resource_allocator { | |||
} | |||
|
|||
static constexpr size_t max_value_type_size() { | |||
return 128U; | |||
return 256U; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it changed?
runtime-light/coroutine/awaitable.h
Outdated
return true; | ||
} | ||
|
||
void await_suspend(std::coroutine_handle<> coro) noexcept { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is something wrong with the design: wait_queue_next_t
always waits for timeout before trying to check fork readiness. So, for example, wait_queue_next($id, 1sec)
is going to wait 1 second anyway, even if next fork is ready in 10ms.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove class wait_queue_next_t
runtime-light/coroutine/awaitable.h
Outdated
if (ready_fork.has_value()) { | ||
timer_awaiter.cancel(); | ||
// todo set here info about prev fork_id | ||
return ForkComponentContext::get().push_fork(std::move(ready_fork.val().second)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Future ID should not be changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix
runtime-light/coroutine/awaitable.h
Outdated
|
||
// ================================================================================================ | ||
|
||
class wait_queue_next_t { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will it work with job workers? Job workers are also represented as futures, so we can wait on them as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix it, check wait_queue_t
#include "runtime-light/stdlib/fork/fork.h" | ||
#include "runtime-light/utils/concepts.h" | ||
|
||
class WaitQueue { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks quite strange. We should not work with raw coroutine handles unless we develop an awaitable. In my opinion, WaitQueue
can be completely removed. WaitQueueContext
can be simplified a lot. Also, keep in mind that wait queues can be used to wait for job workers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
merge wait_next_t
and WaitQueue
@@ -14,6 +14,7 @@ | |||
|
|||
int64_t f$rand() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it defined in that file?
8d0b434
to
55dca84
Compare
c264013
to
d74f418
Compare
} | ||
std::coroutine_handle<> next_awaiter = awaiters.empty() ? std::noop_coroutine() : awaiters.front().awaited_handle; | ||
std::for_each(forks_ids.begin(), forks_ids.end(), [&](int64_t fork_id) { | ||
task_t<fork_result>::awaiter_t task_awaiter{std::addressof(ForkComponentContext::get().forks[fork_id].first)}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this part. I think should be method in ForkComponentContext
for suspend coroutine handle on task_t
d74f418
to
9eebcb3
Compare
General
add buildin functions from runtime realted to wait fork queue
The storage for waiting queues is
WaitQueueContext
. That class is responsible for queues managing. Classwait_queue_t
containstwo queues
: one for forks, second for awaiters.Details