[ruby-core:46039] [ruby-trunk - Bug #6629][Assigned] [PATCH] io.c: avoid rb_thread_wait_fd() if we may call rb_io_wait_readable()

Issue #6629 has been updated by mame (Yusuke Endoh).

Status changed from Open to Assigned
Assignee set to kosaki (Motohiro KOSAKI)


----------------------------------------
Bug #6629: [PATCH] io.c: avoid rb_thread_wait_fd() if we may call rb_io_wait_readable()
https://bugs.ruby-lang.org/issues/6629#change-27645

Author: normalperson (Eric Wong)
Status: Assigned
Priority: Normal
Assignee: kosaki (Motohiro KOSAKI)
Category: 
Target version: 
ruby -v: ruby 2.0.0dev (2012-06-23 trunk 36192) [x86_64-linux]


Blindly calling rb_thread_wait_fd() is an extra, unnecessary
system call in some cases.  Since we already call
rb_io_wait_readable() when encountering EAGAIN, there is no
user-visible change in behavior and a small potential for
speedup by avoiding a system call (especially on regular
filesystem that should never return EAGAIN/EINTR).

This also helps avoid triggering a bugs on some buggy (ancient)
Linux kernels.  I encountered this issue[1] on a CentOS 5.7
machine running the 2.6.18-274.7.1.el5 kernel.  Upgrading to
the 2.6.18-308.8.2.el5 kernel fixes the issue.

This Linux kernel regression I encountered was introduced with
commit 786d7e1612f0b0adb6046f19b906609e4fe8b1ba (Jul 15 2007)
and fixed in
commit dd23aae4f5edf4e1dbd8f7f8013a754ba3253f48 (Sep 11 2007)
I've verified the dd23aae4f5edf4e1dbd8f7f8013a754ba3253f48
change is present in the 2.6.18-308.8.2.el5 (working) kernel
but not in the 2.6.18-274.7.1.el5 (broken) kernel.

I realize this is a 5 year-old (fixed) bug in Linux, but I also
believe Ruby is is wrong to call select()/ppoll() before
encountering EAGAIN.

[1] http://mid.gmane.org/[e-mail]

Note: I left IO#sysread unchanged (with just a comment) since
removing rb_thread_wait_fd() there would change semantics
(as would handling EAGAIN explicitly).



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