Forum: Ruby-core [ruby-trunk - Bug #9036][Open] [PATCH] io.c: make IO#reopen("pathname") atomic for non-stdio

18813f71506ebad74179bf8c5a136696?d=identicon&s=25 normalperson (Eric Wong) (Guest)
on 2013-10-20 06:16
(Received via mailing list)
Issue #9036 has been reported by normalperson (Eric Wong).

----------------------------------------
Bug #9036: [PATCH] io.c: make IO#reopen("pathname") atomic for non-stdio
https://bugs.ruby-lang.org/issues/9036

Author: normalperson (Eric Wong)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.1.0dev (2013-10-20 trunk 43369) [x86_64-linux]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


Since rb_sysopen releases the GVL, calling close(fptr->fd) would
leave a window where accessing the file from another thread can hit
IOError on a closed stream

Instead, create a new, temporary FD via rb_sysopen and call
rb_cloexec_dup2 on it to atomically replace the file fptr->fd points
to.  This leaves no possible window where fptr->fd is invalid to
userspace (even for any threads running w/o GVL).

Without this patch, I need to maintain separate code paths for
atomically reopening (e.g. log rotation) std{in,out,err} vs
other files in a multithreaded application.
18813f71506ebad74179bf8c5a136696?d=identicon&s=25 Eric Wong (Guest)
on 2013-10-20 06:27
(Received via mailing list)
"normalperson (Eric Wong)" <normalperson@yhbt.net> wrote:
> Without this patch, I need to maintain separate code paths for
> atomically reopening (e.g. log rotation) std{in,out,err} vs
> other files in a multithreaded application.

Separate code paths like this:
http://bogomips.org/yahns.git/patch/?id=bcb10abe5
(review greatly appreciated!, thanks!)
9361878d459f1709feec780518946ee5?d=identicon&s=25 unknown (Guest)
on 2014-07-23 06:13
(Received via mailing list)
Issue #9036 has been updated by Yui NARUSE.

Backport changed from 1.9.3: UNKNOWN, 2.0.0: UNKNOWN to 1.9.3: REQUIRED,
2.0.0: REQUIRED, 2.1: REQUIRED

----------------------------------------
Bug #9036: [PATCH] io.c: make IO#reopen("pathname") atomic for non-stdio
https://bugs.ruby-lang.org/issues/9036#change-47971

* Author: Eric Wong
* Status: Closed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* ruby -v: ruby 2.1.0dev (2013-10-20 trunk 43369) [x86_64-linux]
* Backport: 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED
----------------------------------------
Since rb_sysopen releases the GVL, calling close(fptr->fd) would
leave a window where accessing the file from another thread can hit
IOError on a closed stream

Instead, create a new, temporary FD via rb_sysopen and call
rb_cloexec_dup2 on it to atomically replace the file fptr->fd points
to.  This leaves no possible window where fptr->fd is invalid to
userspace (even for any threads running w/o GVL).

Without this patch, I need to maintain separate code paths for
atomically reopening (e.g. log rotation) std{in,out,err} vs
other files in a multithreaded application.


---Files--------------------------------
0001-io.c-make-IO-reopen-pathname-atomic.patch (1.47 KB)
5cf8f058a4c094bb708174fb43e7a387?d=identicon&s=25 unknown (Guest)
on 2014-08-18 15:35
(Received via mailing list)
Issue #9036 has been updated by Tomoyuki Chikanaga.

Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: REQUIRED to
1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONTNEED

r43373 was already included in ruby_2.1.

----------------------------------------
Bug #9036: [PATCH] io.c: make IO#reopen("pathname") atomic for non-stdio
https://bugs.ruby-lang.org/issues/9036#change-48393

* Author: Eric Wong
* Status: Closed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* ruby -v: ruby 2.1.0dev (2013-10-20 trunk 43369) [x86_64-linux]
* Backport: 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONTNEED
----------------------------------------
Since rb_sysopen releases the GVL, calling close(fptr->fd) would
leave a window where accessing the file from another thread can hit
IOError on a closed stream

Instead, create a new, temporary FD via rb_sysopen and call
rb_cloexec_dup2 on it to atomically replace the file fptr->fd points
to.  This leaves no possible window where fptr->fd is invalid to
userspace (even for any threads running w/o GVL).

Without this patch, I need to maintain separate code paths for
atomically reopening (e.g. log rotation) std{in,out,err} vs
other files in a multithreaded application.


---Files--------------------------------
0001-io.c-make-IO-reopen-pathname-atomic.patch (1.47 KB)
8cbb39dadafaf2287a83a13ee4981ec9?d=identicon&s=25 unknown (Guest)
on 2014-09-12 04:21
(Received via mailing list)
Issue #9036 has been updated by Usaku NAKAMURA.

Backport changed from 1.9.3: REQUIRED, 2.0.0: REQUIRED, 2.1: DONTNEED to
2.0.0: DONE, 2.1: DONTNEED

backported into `ruby_2_0_0` at r47545.

----------------------------------------
Bug #9036: [PATCH] io.c: make IO#reopen("pathname") atomic for non-stdio
https://bugs.ruby-lang.org/issues/9036#change-48857

* Author: Eric Wong
* Status: Closed
* Priority: Normal
* Assignee:
* Category:
* Target version:
* ruby -v: ruby 2.1.0dev (2013-10-20 trunk 43369) [x86_64-linux]
* Backport: 2.0.0: DONE, 2.1: DONTNEED
----------------------------------------
Since rb_sysopen releases the GVL, calling close(fptr->fd) would
leave a window where accessing the file from another thread can hit
IOError on a closed stream

Instead, create a new, temporary FD via rb_sysopen and call
rb_cloexec_dup2 on it to atomically replace the file fptr->fd points
to.  This leaves no possible window where fptr->fd is invalid to
userspace (even for any threads running w/o GVL).

Without this patch, I need to maintain separate code paths for
atomically reopening (e.g. log rotation) std{in,out,err} vs
other files in a multithreaded application.


---Files--------------------------------
0001-io.c-make-IO-reopen-pathname-atomic.patch (1.47 KB)
This topic is locked and can not be replied to.