[#69084] [Ruby trunk - Feature #11124] [Open] [PATCH] lib/*: use monotonic clock for timeouts — normalperson@...
Issue #11124 has been reported by Eric Wong.
5 messages
2015/05/06
[#69138] [Ruby trunk - Feature #11136] [PATCH] webrick: avoid fcntl module — nobu@...
Issue #11136 has been updated by Nobuyoshi Nakada.
3 messages
2015/05/12
[#69160] [Ruby trunk - Feature #11146] [PATCH] variable.c: initialize generic_iv_tbl at start — nobu@...
Issue #11146 has been updated by Nobuyoshi Nakada.
4 messages
2015/05/13
[#69175] Re: [Ruby trunk - Feature #11146] [PATCH] variable.c: initialize generic_iv_tbl at start
— Eric Wong <normalperson@...>
2015/05/13
nobu@ruby-lang.org wrote:
[ruby-core:69086] Re: [ruby-trunk - Feature #10718] [Open] IO#close should not raise IOError on closed IO objects.
From:
Eric Wong <normalperson@...>
Date:
2015-05-07 01:39:54 UTC
List:
ruby-core #69086
Eric Wong <normalperson@yhbt.net> wrote: > Thank you for proposing this. I think this will simplify working with > Ruby IO and make me happier since I work with a lot of IO-related code. > Outside of test cases, I don't forsee compatibility problems either. Ugh, I take that back... This can hide existing bugs. For example, I track open connection counts (persistent HTTP connections are expired in a GC-like manner) in the multi-threaded yahns server[1]. Something like: @mtx.synchronize do @count -= 1 io.close end If I get IOError as in 2.2, I'll there is a major bug (probably race condition) fix the code. But now, I may need to add extra checks for io.closed? before every io.close: @mtx.synchronize do @count -= 1 raise "MAJOR BUG!" if io.closed? io.close end Anyways, I'm not sure if many people complained about IOError on IO#close over the past years; so perhaps reverting to 2.2 behavior is safer. [1] http://yahns.yhbt.net/README || git clone git://yhbt.net/yahns