samuel / oriontransfer.org wrote:
> I think that the work being done here is great. However I feel that this PR requires far more scrutiny than it's receiving.

Of course, which is why you don't see me pushing for it's
inclusion in 2.5.  I only present and update it so people can
test it if they're bored.  And I only started working on it
because ko1 seemed interested in it at the time.

I'd be surprised if this gets into 2.6 or any release in the
future.  Nobody besides you and I seems interested in discussing
this anymore; so likely it'll sit here quietly for a few more
years.

Again, I don't make API decisions, I only present options.

> > I am using "double" for timeout since it is more convenient for arithmetic like parts of thread.c. Most platforms have good FP, I think.
> 
> e.g. https://github.com/socketry/nio4r/issues/140

Right.  We already have plenty of threading internals using FP
for timing, as well as the public Ruby APIs for IO.select and
IO#wait_*able.  Internally, at least it's a minor thing to
change all the internal APIs to use "struct timespec" all around
for maximum precision.

> I think it's a great idea to have non-blocking evented IO.
> However, it's not as simple as making read/write non-blocking.
> How about DNS lookups? Filesystem access? The benefit of a
> library based approach as I proposed is that these limitations
> can be clearly part of the contract of a specific library, and
> people can make different libraries to suit their needs, but
> making it part of core Ruby is a slippery slope. If anything,
> it would be better to depend on an established solution for
> this, so that cases like using the system DNS resolver are
> handled correctly (e.g. libuv). Otherwise, this is a HUGE
> addition to the surface area of the ruby interpreter.

We have resolv.rb in stdlib; which was at least popular in 1.8
days.  It's implemented entirely in Ruby, so it automatically
takes advantage of these Thriber changes, and has seen a fair
amount of use back in the 1.8 days (not that DNS has changed
drastically).

So really, the network I/O part is not a big, or even complex
change, it's 1.8 Threads being made an option again for
Ruby 2.x.  I miss 1.8 Threads, but I also like native threads in
1.9/2.x; they each have their place.  And the lightweight
threading for network I/O is what people seem to care about in
other languages (Go, Erlang).  nio4r/libuv and async can still
be an option and I have no intention of breaking compatibility.


Filesystem access: out-of-scope for this...

I definitely do NOT want to try and make this use callbacks and
threadpools behind users' backs, even internally.  It pessimizes
the common hot cache case (which doesn't require waiting); and
more importantly, and I do not want Ruby or any library to
interfere with mountpoint-aware code.

Mountpoint awareness is 100% necessary for me so there's no
queue blocking when one native thread is doing IO on a fast FS
while another native thread is doing IO on a slow FS.  I end up
with dozens or hundreds of threads, because I have dozens or
hundreds of mountpoints of different speeds.  This is an
uncommon use case, I know, but some people need it and the
VM must not get in the way.

So I think anything to deal with FS access specifically is
out-of-scope for this issue.  We already have native Thread
support, and I use it to implement mountpoint-awareness.  Some
of the GVL-release changes to File and Dir for 2.5 will help
with this (which reminds me, I still need to document some of
that in NEWS :x).

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>