[#35631] [Ruby 1.9 - Bug #4558][Open] TestSocket#test_closed_read fails after r31230 — Tomoyuki Chikanaga <redmine@...>

23 messages 2011/04/06

[#35632] [Ruby 1.9 - Bug #4559][Open] Proc#== does not match the documented behaviour — Adam Prescott <redmine@...>

13 messages 2011/04/06

[#35637] [Ruby 1.9 - Bug #4561][Open] 1.9.2 requires parentheses around argument of method call in an array, where 1.8.7 did not — Dave Schweisguth <redmine@...>

9 messages 2011/04/07

[#35666] caching of the ancestor chain — Xavier Noria <fxn@...>

Why does Ruby cache the ancestors chain? I mean, not why the implementation implies that, but why it works that way conceptually.

9 messages 2011/04/09

[#35734] [Ruby 1.9 - Feature #4574][Open] Numeric#within — redmine@...

16 messages 2011/04/13

[#35753] [Ruby 1.9 - Bug #4576][Open] Range#step miss the last value, if end-exclusive and has float number — redmine@...

61 messages 2011/04/14
[#39566] [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number — Marc-Andre Lafortune <ruby-core@...> 2011/09/15

[#39590] [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number — Marc-Andre Lafortune <ruby-core@...> 2011/09/16

[#39593] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number — Tanaka Akira <akr@...> 2011/09/16

2011/9/17 Marc-Andre Lafortune <ruby-core@marc-andre.ca>:

[#39608] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number — Masahiro TANAKA <masa16.tanaka@...> 2011/09/17

I have not been watching ruby-core, but let me give a comment for this issue.

[#35765] [Ruby 1.9 - Bug #4579][Open] SecureRandom + OpenSSL may repeat with fork — redmine@...

27 messages 2011/04/15

[#35866] [Ruby 1.9 - Bug #4603][Open] lib/csv.rb: when the :encoding parameter is not provided, the encoding of CSV data is treated as ASCII-8BIT — yu nobuoka <nobuoka@...>

13 messages 2011/04/24

[#35879] [Ruby 1.9 - Bug #4610][Open] Proc#curry behavior is inconsistent with lambdas containing default argument values — Joshua Ballanco <jballanc@...>

11 messages 2011/04/25

[#35883] [Ruby 1.9 - Bug #4611][Open] [BUG] Segementation fault reported — Deryl Doucette <me@...>

15 messages 2011/04/25

[#35895] [Ruby 1.9 - Feature #4614][Open] [RFC/PATCH] thread_pthread.c: lower RUBY_STACK_MIN_LIMIT to 64K — Eric Wong <normalperson@...>

10 messages 2011/04/25

[ruby-core:35596] [Ruby 1.9 - Feature #4538] [PATCH (cleanup)] avoid unnecessary select() calls before doing I/O

From: Charles Nutter <headius@...>
Date: 2011-04-01 10:01:59 UTC
List: ruby-core #35596
Issue #4538 has been updated by Charles Nutter.


Understood. I read through a bit more code and saw that Ruby uses pthread signalling and RUBY_VM_CHECK_INTS after blocking regions to interrupt blocking operations.

I wonder, though, if depending on this behavior is leading Ruby more and more down the GVL path. The designers of the JVM's core IO libraries, for example, were unable to reconcile concurrent native threads with interruptible IO, due to the impossibility of knowing what state all IO-related data structures are in when the thread is interrupted. As a result, IO channels performing blocking operations are explicitly closed when the thread they block is interrupted.

In JRuby, we simulate interruptible IO by using select as much as possible, and blocking operations against unselectable IO channels are not interruptible. Some of the overhead of select is mitigated by JVM implementers usually using the fastest-possible mechanism to implement it (kqueue, epoll).

It seems that your change (and others like it) makes Ruby even more dependent on kernel-level blocking IO operations always being safely interruptible, and depending on those interruptions to only occur at the exact boundaries defined by the GVL. A future concurrent-threaded Ruby (or other impls that may become concurrent-threaded) may want to consider this, no? And are there any cross-platform concerns from eliminating select in these cases?

I also wonder if there's a race condition here; is it not possible that the interrupt of a thread would fire immediately after the GVL has been released but before the blocking IO operation has fired? Perhaps I'm birdwalking too deep into the vagaries of MRI's IO logic.
----------------------------------------
Feature #4538: [PATCH (cleanup)] avoid unnecessary select() calls before doing I/O
http://redmine.ruby-lang.org/issues/4538

Author: Eric Wong
Status: Open
Priority: Low
Assignee: 
Category: core
Target version: 1.9.x


Please look at http://redmine.ruby-lang.org/issues/4535 before
this one.  That one actually fixes a bug I noticed while working
on this patch.

Ruby 1.9 no longer depends on multiplexed non-blocking I/O
to do its threading and defaults to blocking file descriptors.

As a result, there is no need to check the fd for read/writability when
there is an error check for rb_io_wait_(read|writ)able after the
blocking function.

I also believe the code in io_binwrite() to:
    avoid context switch between "a" and "\n" in STDERR.puts "a".
    [ruby-dev:25080]
...has always been broken under 1.9 with native threads.

Nothing new is broken with test-all and test-rubyspec



-- 
http://redmine.ruby-lang.org

In This Thread