[#35599] Proc#== behaviour on 1.8.7 and 1.9.2 — Adam Prescott <adam@...>
I've encountered a problem when using Proc#== (with both lambdas and
[#35613] [Ruby 1.9 - Feature #4539][Assigned] Array#zip_with — Yui NARUSE <redmine@...>
> http://redmine.ruby-lang.org/issues/4539
Hi,
[#35618] Redmine issues — Benoit Daloze <eregontp@...>
Hello,
[#35621] [Ruby 1.9 - Bug #4555][Open] [PATCH] ext/socket/init.c: rsock_connect retries on interrupt — Eric Wong <normalperson@...>
[#35629] [Ruby 1.9 - Bug #4473] Calling return within begin still executes else — Mayank Kohaley <redmine@...>
[#35631] [Ruby 1.9 - Bug #4558][Open] TestSocket#test_closed_read fails after r31230 — Tomoyuki Chikanaga <redmine@...>
> ----------------------------------------
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
Tomoyuki Chikanaga <redmine@ruby-lang.org> wrote:
> Issue #4558 has been updated by Eric Wong.
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
[#35632] [Ruby 1.9 - Bug #4559][Open] Proc#== does not match the documented behaviour — Adam Prescott <redmine@...>
(2012/11/28 16:10), matz (Yukihiro Matsumoto) wrote:
I believe this will be a spec change, albeit a small one. Can we
[#35636] [Ruby 1.9 - Feature #4560][Open] [PATCH] lib/net/protocol.rb: avoid exceptions in rbuf_fill — Eric Wong <redmine@...>
[#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@...>
[#35644] [Ruby 1.8 - Bug #4563][Open] Dir#tell broken — Daniel Berger <redmine@...>
[#35648] mvm branch status? — Eric Wong <normalperson@...>
Hello, I noticed the "mvm" branch in SVN hasn't been updated in over a year.
Hi Eric.
Has there been any thought on solving the C extension problem in MVM? In the present state, I've stopped working on it in Rubinius because there is no workable solution if there are C extensions in the mix.
Evan Phoenix <evan@fallingsnow.net> wrote:
On Thu, Apr 7, 2011 at 6:18 PM, Eric Wong <normalperson@yhbt.net> wrote:
[#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.
Ah, in case it is not clear, where I find the metaphor broken is in that you can add methods to a mixin and have them available in classes that already included it, but if you include a new ancestor, then method dispatch in classes that already included the module aren't aware of the new chain.
Hi,
On Fri, Apr 8, 2011 at 7:56 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:
[#35678] [Ruby 1.9 - Bug #4564][Open] mingw-w64, truncate, ftruncate and ftello -- properly evalute it's existence — Luis Lavena <redmine@...>
[#35699] [Ruby 1.9 - Feature #4568][Open] [PATCH] file.c (rb_group_member): kill 256K of stack usage — redmine@...
[#35707] [Ruby 1.9 - Feature #4569][Open] Replace IPAddr with IPAddress — redmine@...
[#35713] [Ruby 1.9 - Bug #4571][Open] YAML.load given an ISO8601 timestamp creates an incorrect value for usec — redmine@...
[#35734] [Ruby 1.9 - Feature #4574][Open] Numeric#within — redmine@...
[#35753] [Ruby 1.9 - Bug #4576][Open] Range#step miss the last value, if end-exclusive and has float number — redmine@...
Hi,
2011/9/16 Kenta Murata <muraken@gmail.com>:
2011/9/16 Marc-Andre Lafortune <ruby-core@marc-andre.ca>:
On 16 September 2011 15:49, Tanaka Akira <akr@fsij.org> wrote:
Can somebody please reopen this issue? Since the test suite fix is
2011/9/17 Marc-Andre Lafortune <ruby-core@marc-andre.ca>:
2011/9/17 Tanaka Akira <akr@fsij.org>:
(2011/09/17 9:07), Tanaka Akira wrote:
I have not been watching ruby-core, but let me give a comment for this issue.
2011/9/17 Masahiro TANAKA <masa16.tanaka@gmail.com>:
2011/9/20 Tanaka Akira <akr@fsij.org>:
I haven't explained the reason of the error estimation in
On 21 September 2011 14:25, masa <masa16.tanaka@gmail.com> wrote:
[#35754] [Ruby 1.9 - Bug #4577][Open] (int...float).max should not raise an error — redmine@...
[#35759] [Ruby 1.8 - Bug #4578][Open] Fixnum.freeze not frozen? — redmine@...
[#35765] [Ruby 1.9 - Bug #4579][Open] SecureRandom + OpenSSL may repeat with fork — redmine@...
[#35777] hashes are not consistent across ruby processes? — Roger Pack <rogerdpack2@...>
Hello all.
[#35813] [Ruby 1.9 - Bug #4320] Bus Error in digest/sha2 on sparc — redmine@...
[#35814] [Ruby 1.9 - Bug #4320] Bus Error in digest/sha2 on sparc — redmine@...
[#35825] [Ruby 1.8 - Bug #4587][Open] RMATCH_REGS definition is wrong — redmine@...
[#35828] [Ruby 1.9 - Feature #4589][Open] add Queue#each() method and include Enumerable — redmine@...
[#35830] [Ruby 1.9 - Feature #3436] Spawn the timer thread lazily — redmine@...
[#35850] [Ruby 1.9 - Feature #4189] FileUtils#ln_r — Sakuro OZAWA <redmine@...>
[#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@...>
On Sun, Apr 24, 2011 at 1:33 AM, yu nobuoka <nobuoka@r-definition.com>wrote:
2011/4/25 James Gray <james@graysoftinc.com>:
On Sun, Apr 24, 2011 at 11:29 PM, NARUSE, Yui <naruse@airemix.jp> wrote:
[#35879] [Ruby 1.9 - Bug #4610][Open] Proc#curry behavior is inconsistent with lambdas containing default argument values — Joshua Ballanco <jballanc@...>
[#35883] [Ruby 1.9 - Bug #4611][Open] [BUG] Segementation fault reported — Deryl Doucette <me@...>
[#35895] [Ruby 1.9 - Feature #4614][Open] [RFC/PATCH] thread_pthread.c: lower RUBY_STACK_MIN_LIMIT to 64K — Eric Wong <normalperson@...>
[#35923] [Ruby 1.9 - Feature #4621][Open] NilClass#to_hash — Tsuyoshi Sawada <sawadatsuyoshi@...>
[#35933] [Ruby 1.9 - Bug #4623][Open] Consistent crash related to action_mailer — Alex Neth <alex@...>
[#35942] change in timeout error — Roger Pack <rogerdpack2@...>
Hello. Sorry if this is a repeat...
[#35943] [Ruby 1.9 - Feature #3905] rb_clear_cache_by_class() called often during GC for non-blocking I/O — Motohiro KOSAKI <kosaki.motohiro@...>
[ruby-core:35600] Re: [Ruby 1.9 - Feature #4538] [PATCH (cleanup)] avoid unnecessary select() calls before doing I/O
On Fri, Apr 1, 2011 at 4:57 PM, Eric Wong <normalperson@yhbt.net> wrote: > Charles Nutter <headius@headius.com> wrote: >> 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. > > I don't think so, even if threads are interrupted they're resumed after > the signal handler is done (or the process is dying anyways and we don't > care). If the interrupt is to raise an exception then that could get > messy[1], but for the general case of signal handlers it's not an issue. I'm speaking specifically of Thread#raise and Thread#kill, which if used to interrupt a thread could potentially leave the IO channel in an unknown state (due to interrupting during a system call). On the JVM, all process-level signals are handled by a separate thread, so they are never run on user threads and that's not a concern for us. JRuby has real concurrent threads, so regardless of what blocking calls we make other threads will continue to run (i.e. we have no need for BLOCKING_REGION-tyle GVL logic). So ultimately it's only being able to kill or raise in an arbitrary thread that led us to make JRuby IO logic use selection to get around the effects of interrupting blocking IO calls I mentioned below. Long story short, how does MRI guarantee that the underlying IO is in a reliable state when the thread accessing it can be interrupted permanently? It seems like doing most blocking at a consistent point (like a select call) is safer. And I am mostly just trying to understand how it's consistently safe to interrupt a system-level IO call. >> As a result, IO channels performing blocking operations >> are explicitly closed when the thread they block is interrupted. > > That is terrible. I'd never touch a platform that does that. Well, I tend not to touch platforms that expose or depend on specific platform details, like MRI does in *many* places (and now more places with your patch, I think). I like my code to work the same on all platforms. That said, I admit it's inconvenient, but I understand the reasoning. You have to understand the JVM is trying to smooth over the platform-specific details of IO across lots of platforms, many of them not POSIX. If you can't guarantee to user code what the state of an IO channel will be when interrupting system-level code, it's a pretty clean option to say "don't do that, or we'll close the stream" and point users toward a safely interruptible option like select. We've managed to work with that situation and mostly emulate MRI's IO behavior, so in practice it's more a nuisance than anything else. > If there are cross-platform concerns, the functions that wrap select() > should be made no-op on platforms where select() is not needed (on > all POSIX-like ones, I expect) and not interfere with platforms where > they're not needed. > > Regardless, there'll always be a set of IO operations that can never be > interrupted. That doesn't bother me at all since the rest of the VM > still runs. I'd rather just not use select()/poll() at all for > "blocking" I/O calls. That seems good on the surface, but it's depending on those blocking operations having consistent state after being interrupted across platforms. That seems like it would be easier to guarantee at a "select" level, but I admit I'm trying to understand if that's true. If you can't guarantee that the underlying IO channels are in a consistent state (ideally the *same* state regardless of platform) then writing to IO becomes a bunch of platform-specific checks in user code just like you'd have to write in C. The structure of Ruby's APIs has always been to provide a reasonably consistent view of system-level APIs so you don't have to do that. >> 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. > > So a signal handler might fire and the syscall would just continue and > not fail with EINTR. No big deal, it'll just finish the syscall before > checking for interrupts. Except that you've now fired your Thread#kill or Thread#raise and the thread is never going to see it. If the contract of kill and raise is that "we'll try to kill or raise in the target thread, but no guarantees if it will do anything at all" I'm fine with that, but that hasn't been the expectation of Ruby users up to now. I'm not sure if this is actually a problem or not...MRI's cross-thread event behavior is rather involved. > The real race condition is relying on select()/poll() at all for > readability. select()/poll() returning success _never_ guarantees an > operation won't block due to spurious wakeups and shared IO across > multiple threads/processes. That's certainly true, but any code using select would not just blindly proceed to a blocking call after wakeup...it would check that the IO channel is actually ready, and if not go into select again. I don't see how that makes the consistency and reliability of blocking on selection less attractive than interrupting arbitrary kernel-level calls. - Charlie