From: Eric Wong Date: 2018-01-26T19:13:43+00:00 Subject: [ruby-core:85136] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid samuel@oriontransfer.org wrote: > In async, I called it `Async::Task`. I think task is a good > name for this kind of thing. In your case, you might want to > consider `Thread::Task`. Since, the lexicographic nesting is > similar to the logical nesting. I prefer shorter names; and I'm not sure if Thread::Task makes sense since it's an alternative to Thread (in some situations); not a helper to Thread (unlike Mutex/Queue/etc). > Regarding kqueue bugs. macOS kqueue implementation is > horrendous. So, `nio4r` doesn't use it AFAIK. Yes, there's also a select() implementation which should be a safe fallback for everybody (not scalable, of course). I'm not sure if OpenBSD/NetBSD/Dragonfly have acceptable kqueue implementations, nowadays, either (FreeBSD seems fine). I will add notes to guide porters into disabling kqueue support, either broadly or fine-grained (per-type), or better, eventually fixing their native kqueue implementations. I also intend to try aio-poll support in future Linux versions (currently under development). > Do you have explicit reactor, or is it implicit per-thread or > per-process? Implicit per-process, and lazily created. kqueue and epoll persistent data structures in the kernel are completely safe to use across multiple threads. select needs no persistent structure in the kernel. Userspace structures are of course done in a thread-safe way and will be adjusted for guilds or GVL removal. If guilds end up being what I expect them to be (implemented via native threads), reactor will likely remain per-process since FDs are still per-process. Some structures and locking will be adjusted for guilds, of course. Unsubscribe: