Andy Pan
Andy Pan
@oranagra @zuiderkwast Can we move forward with this?
> what do you mean? i might not recall all the details, but i think it is already resolved. It can be considered as resolved, but still, there is a...
Also, `kqueue` and `evport` are working with nanosecond precision as well. It's good to keep `epoll` in sync with the current `kqueue` and `evport` in `redis`.
> they're working with nanoseconds because they don't have any other option. True. But we don't need other options because the only option provided by `kqueue` and `evport` has been...
> > From what I've stated above, I think this `epoll_pwait2()` is the real _**simple**_ implementation here. > > There would be simplicity if we could get rid of `epoll_wait()`....
The current approach creates complexity during run time and also it is an approximate workaround (might be good enough for users using =v5.11 kernel), and this PR eliminates that run-time...
> We have to maintain all the code we add in the repo. Reading, reviewing, testing that it's correct in all cases is what matters. In that sense I understand...
> Do you happen to know if they work with `select` correctly? There is a whole fallback path with `uv__stream_try_select` already implemented to support other kinds of descriptors that might...
Any new comments on this?