[#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
5 messages
2011/04/01
[#35613] [Ruby 1.9 - Feature #4539][Assigned] Array#zip_with — Yui NARUSE <redmine@...>
11 messages
2011/04/05
[#35617] Re: [Ruby 1.9 - Feature #4539][Assigned] Array#zip_with
— Benoit Daloze <eregontp@...>
2011/04/05
> http://redmine.ruby-lang.org/issues/4539
[#35673] Re: [Ruby 1.9 - Feature #4539][Assigned] Array#zip_with
— Kenta Murata <muraken@...>
2011/04/09
Hi,
[#35618] Redmine issues — Benoit Daloze <eregontp@...>
Hello,
6 messages
2011/04/05
[#35621] [Ruby 1.9 - Bug #4555][Open] [PATCH] ext/socket/init.c: rsock_connect retries on interrupt — Eric Wong <normalperson@...>
7 messages
2011/04/05
[#35708] [Ruby 1.9 - Bug #4555] [PATCH] ext/socket/init.c: rsock_connect retries on interrupt
— redmine@...
2011/04/11
[#35629] [Ruby 1.9 - Bug #4473] Calling return within begin still executes else — Mayank Kohaley <redmine@...>
4 messages
2011/04/06
[#35631] [Ruby 1.9 - Bug #4558][Open] TestSocket#test_closed_read fails after r31230 — Tomoyuki Chikanaga <redmine@...>
23 messages
2011/04/06
[#35641] Re: [Ruby 1.9 - Bug #4558][Open] TestSocket#test_closed_read fails after r31230
— KOSAKI Motohiro <kosaki.motohiro@...>
2011/04/07
> ----------------------------------------
[#35647] Re: [Ruby 1.9 - Bug #4558][Open] TestSocket#test_closed_read fails after r31230
— Eric Wong <normalperson@...>
2011/04/07
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
[#35665] [Ruby 1.9 - Bug #4558] TestSocket#test_closed_read fails after r31230
— Tomoyuki Chikanaga <redmine@...>
2011/04/09
[#35669] Re: [Ruby 1.9 - Bug #4558] TestSocket#test_closed_read fails after r31230
— Eric Wong <normalperson@...>
2011/04/09
Tomoyuki Chikanaga <redmine@ruby-lang.org> wrote:
[#35715] [Ruby 1.9 - Bug #4558][Assigned] TestSocket#test_closed_read fails after r31230
— redmine@...
2011/04/12
[#35716] [Ruby 1.9 - Bug #4558] TestSocket#test_closed_read fails after r31230
— redmine@...
2011/04/12
[#35726] Re: [Ruby 1.9 - Bug #4558] TestSocket#test_closed_read fails after r31230
— KOSAKI Motohiro <kosaki.motohiro@...>
2011/04/12
> Issue #4558 has been updated by Eric Wong.
[#35746] Re: [Ruby 1.9 - Bug #4558] TestSocket#test_closed_read fails after r31230
— Eric Wong <normalperson@...>
2011/04/13
KOSAKI Motohiro <kosaki.motohiro@gmail.com> wrote:
[#35632] [Ruby 1.9 - Bug #4559][Open] Proc#== does not match the documented behaviour — Adam Prescott <redmine@...>
13 messages
2011/04/06
[#50251] [ruby-trunk - Bug #4559] Proc#== does not match the documented behaviour
— "matz (Yukihiro Matsumoto)" <matz@...>
2012/11/28
[#50252] Re: [ruby-trunk - Bug #4559] Proc#== does not match the documented behaviour
— SASADA Koichi <ko1@...>
2012/11/28
(2012/11/28 16:10), matz (Yukihiro Matsumoto) wrote:
[#50505] Re: [ruby-trunk - Bug #4559] Proc#== does not match the documented behaviour
— Charles Oliver Nutter <headius@...>
2012/12/03
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@...>
6 messages
2011/04/07
[#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
[#35644] [Ruby 1.8 - Bug #4563][Open] Dir#tell broken — Daniel Berger <redmine@...>
6 messages
2011/04/07
[#35648] mvm branch status? — Eric Wong <normalperson@...>
Hello, I noticed the "mvm" branch in SVN hasn't been updated in over a year.
10 messages
2011/04/07
[#35649] Re: mvm branch status?
— Urabe Shyouhei <shyouhei@...>
2011/04/07
Hi Eric.
[#35650] Re: mvm branch status?
— Evan Phoenix <evan@...>
2011/04/07
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.
[#35652] Re: mvm branch status?
— Eric Wong <normalperson@...>
2011/04/07
Evan Phoenix <evan@fallingsnow.net> wrote:
[#35691] Re: mvm branch status?
— Charles Oliver Nutter <headius@...>
2011/04/10
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.
9 messages
2011/04/09
[#35667] Re: caching of the ancestor chain
— Xavier Noria <fxn@...>
2011/04/09
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.
[#35668] Re: caching of the ancestor chain
— Yukihiro Matsumoto <matz@...>
2011/04/09
Hi,
[#35692] Re: caching of the ancestor chain
— Charles Oliver Nutter <headius@...>
2011/04/10
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@...>
8 messages
2011/04/09
[#35699] [Ruby 1.9 - Feature #4568][Open] [PATCH] file.c (rb_group_member): kill 256K of stack usage — redmine@...
4 messages
2011/04/11
[#35707] [Ruby 1.9 - Feature #4569][Open] Replace IPAddr with IPAddress — redmine@...
13 messages
2011/04/11
[#35713] [Ruby 1.9 - Bug #4571][Open] YAML.load given an ISO8601 timestamp creates an incorrect value for usec — redmine@...
5 messages
2011/04/11
[#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
[#39567] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— Kenta Murata <muraken@...>
2011/09/16
Hi,
[#39569] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— "NARUSE, Yui" <naruse@...>
2011/09/16
2011/9/16 Kenta Murata <muraken@gmail.com>:
[#39582] 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/16 Marc-Andre Lafortune <ruby-core@marc-andre.ca>:
[#39584] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— Michal Suchanek <hramrach@...>
2011/09/16
On 16 September 2011 15:49, Tanaka Akira <akr@fsij.org> wrote:
[#39198] [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— Vit Ondruch <v.ondruch@...>
2011/08/30
[#39508] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— V咜 Ondruch <v.ondruch@...>
2011/09/13
Can somebody please reopen this issue? Since the test suite fix is
[#39510] [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— Vit Ondruch <v.ondruch@...>
2011/09/13
[#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>:
[#39595] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— Tanaka Akira <akr@...>
2011/09/17
2011/9/17 Tanaka Akira <akr@fsij.org>:
[#39604] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— "NARUSE, Yui" <naruse@...>
2011/09/17
(2011/09/17 9:07), Tanaka Akira wrote:
[#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.
[#39637] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— Tanaka Akira <akr@...>
2011/09/20
2011/9/17 Masahiro TANAKA <masa16.tanaka@gmail.com>:
[#39655] 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/21
2011/9/20 Tanaka Akira <akr@fsij.org>:
[#39656] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— masa <masa16.tanaka@...>
2011/09/21
I haven't explained the reason of the error estimation in
[#39657] Re: [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number
— Michal Suchanek <hramrach@...>
2011/09/21
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@...
8 messages
2011/04/14
[#35759] [Ruby 1.8 - Bug #4578][Open] Fixnum.freeze not frozen? — redmine@...
6 messages
2011/04/14
[#35761] [Ruby 1.8 - Bug #4578] Fixnum.freeze not frozen?
— redmine@...
2011/04/15
[#35765] [Ruby 1.9 - Bug #4579][Open] SecureRandom + OpenSSL may repeat with fork — redmine@...
27 messages
2011/04/15
[#35771] [Ruby 1.9 - Bug #4579] SecureRandom + OpenSSL may repeat with fork
— redmine@...
2011/04/15
[#35773] [Ruby 1.9 - Bug #4579] SecureRandom + OpenSSL may repeat with fork
— redmine@...
2011/04/15
[#35774] [Ruby 1.9 - Bug #4579] SecureRandom + OpenSSL may repeat with fork
— redmine@...
2011/04/15
[#35779] [Ruby 1.9 - Bug #4579] SecureRandom + OpenSSL may repeat with fork
— redmine@...
2011/04/15
[#35822] [Ruby 1.9 - Bug #4579] SecureRandom + OpenSSL may repeat with fork
— redmine@...
2011/04/20
[#35769] [Ruby 1.9 - Bug #4579] SecureRandom + OpenSSL may repeat with fork
— redmine@...
2011/04/15
[#35777] hashes are not consistent across ruby processes? — Roger Pack <rogerdpack2@...>
Hello all.
5 messages
2011/04/15
[#35813] [Ruby 1.9 - Bug #4320] Bus Error in digest/sha2 on sparc — redmine@...
1 message
2011/04/19
[#35814] [Ruby 1.9 - Bug #4320] Bus Error in digest/sha2 on sparc — redmine@...
1 message
2011/04/19
[#35825] [Ruby 1.8 - Bug #4587][Open] RMATCH_REGS definition is wrong — redmine@...
4 messages
2011/04/20
[#35828] [Ruby 1.9 - Feature #4589][Open] add Queue#each() method and include Enumerable — redmine@...
10 messages
2011/04/20
[#35830] [Ruby 1.9 - Feature #3436] Spawn the timer thread lazily — redmine@...
1 message
2011/04/20
[#35850] [Ruby 1.9 - Feature #4189] FileUtils#ln_r — Sakuro OZAWA <redmine@...>
1 message
2011/04/22
[#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
[#35873] Re: [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
— James Gray <james@...>
2011/04/25
On Sun, Apr 24, 2011 at 1:33 AM, yu nobuoka <nobuoka@r-definition.com>wrote:
[#35875] Re: [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
— "NARUSE, Yui" <naruse@...>
2011/04/25
2011/4/25 James Gray <james@graysoftinc.com>:
[#35878] Re: [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
— James Gray <james@...>
2011/04/25
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@...>
11 messages
2011/04/25
[#35892] [Ruby 1.9 - Feature #4610] Proc#curry behavior is inconsistent with lambdas containing default argument values
— Joshua Ballanco <jballanc@...>
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
[#35923] [Ruby 1.9 - Feature #4621][Open] NilClass#to_hash — Tsuyoshi Sawada <sawadatsuyoshi@...>
4 messages
2011/04/27
[#35933] [Ruby 1.9 - Bug #4623][Open] Consistent crash related to action_mailer — Alex Neth <alex@...>
7 messages
2011/04/27
[#35942] change in timeout error — Roger Pack <rogerdpack2@...>
Hello. Sorry if this is a repeat...
4 messages
2011/04/29
[#35943] [Ruby 1.9 - Feature #3905] rb_clear_cache_by_class() called often during GC for non-blocking I/O — Motohiro KOSAKI <kosaki.motohiro@...>
3 messages
2011/04/29
[ruby-core:35609] Re: [Ruby 1.9 - Feature #4538] [PATCH (cleanup)] avoid unnecessary select() calls before doing I/O
From:
Eric Wong <normalperson@...>
Date:
2011-04-04 18:19:41 UTC
List:
ruby-core #35609
Charles Oliver Nutter <headius@headius.com> wrote:
> 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).
<snip>
> 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.
MRI should (already appears to) define rb_thread_blocking_region() as a
cancellation point for Thread#raise and Thread#kill so any C code should
tidy things up before entering/leaving a blocking region.
> And I am mostly just trying to understand how it's consistently safe
> to interrupt a system-level IO call.
The actual syscall are usually very trivial and has few (if any)
user-visible internal structures to worry about unless memory was
malloc()-ed for it (in the case of select() + rb_fd_init()).
The kernel is expected to handle all the internal structures for
interruptibility (it only exposes an opaque integer descriptor to
userspace).
> >> 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.
We'll have to agree to differ here :)
I choose to work on my platform (Linux) because I see more benefits to it
than alternatives and would like to take advantage of strengths of it.
> > 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.
Upon further inspection, I see MRI uses select() only in 100ms
increments while checking for interrupts on win32. That may be because
win32 can't interrupt syscalls like select(), but all other platforms
MRI supports can...
I shall update my patch to only select() before I/O on win32 is somebody
can confirm it is needed. On POSIX, select() never wakes up unless it
receives a signal (or a descriptor is ready).
> >> 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.
I don't think "never" is correct, but seeing it too late seems to be
a current problem...
> 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.
Refiring signal pthread_kill() is probably needed if the syscall blocks
a long time:
blocking_thread interrupting_thread
-----------------------------------------------------------
check ints => nothing
release gvl
Thread#raise
set interrupt flag
pthread_kill()
long syscall
(long time passes...)
check ints => finally sees Thread#raise
In this case for delivering Thread#raise in timely fashion, the
interrupting thread will need to set a timer to refire pthread_kill() in
a loop if it detects blocking_thread hasn't reacted to the signal, yet.
Multiple EINTRs from pthread_kill() wouldn't be any more/less harmful
than one EINTR.
I realize doing a short 100ms poll()/select() like win32 does is
possible for timelier delivery of Thread#raise/Thread#kill, but I'd
rather avoid those expensive syscalls for general case since
Thread#raise/Thread#kill is not common.
> > 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.
Blocking syscalls can be better for some cases (e.g. accept() under
Linux) since the kernel can implement behavior to wake up exactly one
waiter on a ready client, whereas with select()/poll(), all the waiters
get woken. I try to take advantage of that (avoids doubling up on
syscalls made) when possible.
--
Eric Wong