zverok (Victor Shepelev) wrote in #note-3: > https://docs.ruby-lang.org/en/master/doc/scheduler_md.html#label-IO > ... Ah. I tested it again with UDPSocket, and everything works fine. It looks like it is the problem mentioned in the sc...dsh0416 (Delton Ding)
Here is the given example code for reproduction the bug: ```ruby rd, wr = IO.pipe scheduler = Evt::Scheduler.new # Any scheduler including the test scheduler in the ruby repo could reproduce the same problem. message = nil Fiber...dsh0416 (Delton Ding)
Yes. I was just figured out that the scheduler is an example in the tests, where the real scheduler is designed to be separated from the ruby-core.dsh0416 (Delton Ding)
The benchmark looks good. I've tested with similar code, and it's 46x slower on my machine. It looks like `epoll` is highly depended on the time that `epoll_ctl` engaged. Since the scheduler now have other registration control includ...dsh0416 (Delton Ding)
Thanks for advice. To separate the process of registration and wait is a good idea for performance. Since even the `select` itself could also take advantages from this, and simplify the whole I/O multiplexing process.dsh0416 (Delton Ding)
In general, event handling gems like nio4r could provide a similar `select` interface with multiple backends including select, kqueue and epoll support. On the side of Ruby meta-programming, this part is easy to be implemented, and coul...dsh0416 (Delton Ding)
It should greatly improve the performance. Advanced registration is a feature of `epoll`, but the performance is also an important part for it. The benchmark from libevent shows the performance of epoll and poll or select, are on a t...dsh0416 (Delton Ding)
dsh0416 (Delton Ding)06:27 PM Ruby Revision c6d7e02b (git): Enable `Fiber.current` and `Fiber#alive?` call inside ractor