[#87773] timer thread [was Re: [ruby-alerts:7905] failure alert on trunk-asserts@silicon-docker (NG (r63844))] — Eric Wong <normalperson@...>
> test_all <main>: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken
[#87836] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been reported by ko1 (Koichi Sasada).
[email protected] wrote:
On 2018/07/06 18:47, Eric Wong wrote:
[#87847] undefined symbol: mjit_init_p — Leam Hall <leamhall@...>
I pulled Ruby trunk on 3 Jul and am now getting errors similar to the
QXMgSSB0b2xkIHlvdSwgYG1ha2UgaW5zdGFsbGAgaXMgbmVlZGVkIHRvIG1ha2UgUnVieSB3b3Jr
T25lIG1vcmUgcmVhc29uIGZvciBodHRwczovL2J1Z3MucnVieS1sYW5nLm9yZy9pc3N1ZXMvMTM2
[#87986] [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt — mame@...
Issue #14915 has been updated by mame (Yusuke Endoh).
[email protected] wrote:
normalperson (Eric Wong) wrote:
[#88088] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — normalperson@...
Issue #14937 has been reported by normalperson (Eric Wong).
[#88104] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been updated by ko1 (Koichi Sasada).
[#88173] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — Greg.mpls@...
Issue #14950 has been reported by MSP-Greg (Greg L).
[#88189] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — nobu@...
Issue #14950 has been updated by nobu (Nobuyoshi Nakada).
[#88199] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — takashikkbn@...
Issue #14937 has been updated by k0kubun (Takashi Kokubun).
[email protected] wrote:
> yet, sky3 had a failure at
> http://ci.rvm.jp/results/trunk@P895/1173951
> > http://ci.rvm.jp/results/trunk@P895/1173951
[ruby-core:88007] [Ruby trunk Misc#14907] [PATCH] io.c: do not close inherited FDs by default
Issue #14907 has been updated by akr (Akira Tanaka).
I understand that FD inheritance dependent program doesn't work well with Ruby.
But I doubt that all external library create FDs with close-on-exec now.
spawn's close_others option would be useful workaround to avoid FD leak
with such (problematic) library.
So, I'm reluctant that removing close_others feature.
It means that we lose the workaround.
However, turn off close_others by default (for spawn and IO.popen) seems possible choice for me.
It is difficult to see how many the problematic libraries actually exists
with closing FDs by default.
----------------------------------------
Misc #14907: [PATCH] io.c: do not close inherited FDs by default
https://bugs.ruby-lang.org/issues/14907#change-73025
* Author: normalperson (Eric Wong)
* Status: Open
* Priority: Normal
* Assignee: akr (Akira Tanaka)
----------------------------------------
io.c: do not close inherited FDs by default
While I fully agree Ruby should create FDs with close-on-exec by
default (as it has since 2.0.0); I don't believe Ruby should be
arbitrarily closing file descriptors it does not know about.
The following is an example (using mwrap[1]) where closing
inherited FDs is harmful.
MWRAP=dump_fd:99 mwrap make -j4 exam 99>>mwrap.out
I only found one minor regression from this change in
test/lib/test/unit.rb as IO.new does not set close-on-exec
when using jobserver FDs from make. A possible change
is to make IO.new set FD_CLOEXEC by default.
[1] https://80x24.org/mwrap/README.html
---Files--------------------------------
0001-io.c-do-not-close-inherited-FDs-by-default.patch (4.45 KB)
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>