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: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>