Qi
Qi
@Darksonn I think it is hard to eyeball the correctness of this code snippet on both master and PR branch. I'm going to close this PR later, and try to...
Closed this PR because the current function flow is highly complicated, which causes too much safety comment, it brings too much mental burden for developer. I will try to make...
> Do we need to take into account things like this: https://github.com/openresty/lua-nginx-module?tab=readme-ov-file#lua_regex_cache_max_entries > > Aka in Lua PCRE regex caches we have a upper bound. @bungle Let's say the customer...
@nowNick Could you resolve merge conflicts?
> it's possible to see head larger than tail I think `head > tail` is intentional, given that this queue is essentially a ring buffer. > I cannot see any...
> The head and tail only increase and never decrease. There are some usage of wrapping_add in the implementation. * https://github.com/tokio-rs/tokio/blob/c38de96b9478c29a08805a4be7e351fdca8bb43a/tokio/src/runtime/scheduler/multi_thread/queue.rs#L247 * https://github.com/tokio-rs/tokio/blob/c38de96b9478c29a08805a4be7e351fdca8bb43a/tokio/src/runtime/scheduler/multi_thread/queue.rs#L295-L296 * https://github.com/tokio-rs/tokio/blob/c38de96b9478c29a08805a4be7e351fdca8bb43a/tokio/src/runtime/scheduler/multi_thread/queue.rs#L323 * https://github.com/tokio-rs/tokio/blob/c38de96b9478c29a08805a4be7e351fdca8bb43a/tokio/src/runtime/scheduler/multi_thread/queue.rs#L366 I'm glad to...
> 1. The owner thread A increased tail. > 2. Thread B stole data and increased head. > 3. It's possible for thread C to only see the update written...
@Darksonn Thanks for your review, I believe you review PR on a more holistic level, which helps to accurately determine downstream impacts. I just drew a diagram to help me...
> Is there any case that worker C thinks that A has not yet finished pushing the task to its local queue? Worker A's modification on `tail` is always visible...
https://github.com/tokio-rs/tokio/blob/ab8d7b82a1252b41dc072f641befb6d2afcb3373/tokio/src/time/clock.rs#L287-L295 This panic was triggered by line 294, I think we can just use `checked_add(duration).unwrap_else(Instand::far_future)` to avoid runtime panic like what the tokio did while `new_timeout()`. https://github.com/tokio-rs/tokio/blob/ab8d7b82a1252b41dc072f641befb6d2afcb3373/tokio/src/time/sleep.rs#L123-L130