[#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:35755] Re: [Ruby 1.9 - Bug #4558] TestSocket#test_closed_read fails after r31230

From: Eric Wong <normalperson@...>
Date: 2011-04-14 20:39:25 UTC
List: ruby-core #35755
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
> > KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
> >> > Issue #4558 has been updated by Eric Wong.
> following scenario should be happen too.
> 
> CPU1                    CPU2                    CPU3
> -------------------------------------------------------------------
> open() -> 5
>                              close(5)
>                                                          open() -> 5
> read(5) -> success, but read different data.

OK, I'm starting to think there's no safe way to handle these
situations, especially with MVM on the horizon.  Just telling users to
stop doing close() in a different thread is probably the best way to
go...

> >> Hmm...
> >> If windows can't implement close() case, I doubt r30852 is correct fix.
> >> Is this really worth that *nix and windows have different spec?
> >
> > If r30852 is reverted, Linux (and maybe other *nix) will still break
> > threads out of blocking read/write with EBADF and
> > rb_io_wait_*able(fptr->fd) will raise IOError as long as we
> > assign fptr->fd = -1 before the actual close() call in IO#close.
> >
> > Maybe Windows (and possibly other OS) will be forced to call do_select()
> > to implement behavior consistent with Linux.
> 
> ???
> I'm sorry, I haven't catch your point.
> Which issue is solved by calling do_select()?

It can reduce the likelyhood of read() being uninterruptable since
do_select() will sleep in 100ms intervals to check for interrupts on
win.  There's still a small chance of blocking read() since select()
can have false positives and other threads could've drained the data...

> > On a related note, r30852 also has the problem with making IO#close an
> > O(n) operation since it needs to scan through all threads (and I'd like
> > to run thousands of threads :>).
> 
> I have no opinion. I like faster software, but I haven't seen close
> makes performance bottleneck.

Contrived test case, but it gets worse as nr_thread increases:

# ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]
  0.010000   0.000000   0.010000 (  0.007288)

# ruby 1.9.3dev (2011-04-14 trunk 31267) [x86_64-linux]
  0.030000   0.000000   0.030000 (  0.033881)
-----------------------------8< -------------------------
require "benchmark"
nr_thread = 1_000
nr_close = 1_000

threads = nr_thread.times.map { Thread.new { sleep } }
puts(Benchmark.measure do
  nr_close.times do
    File.open(__FILE__).close
  end
end)
threads.each { |thr| thr.run }.each { |thr| thr.join }
-- 
Eric Wong

In This Thread