[#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:88015] Re: [Ruby trunk Feature#5446] at_fork callback API
[email protected] wrote: > IMHO, this is is still very much needed for cases using plain fork(). > The default close-on-exec behavior is irrelevant for fork() without exec() and does not help. Agreed. > Inheriting, e.g., a database connection in such a case is > extremely harmful (data corruption or leaking sensitive data) > and a common pitfall. It's been a known problem for decades, now (at least since the days of mod_perl + DBI on Apache 1.x); and AFAIK there's no data leaks from it. Anybody who makes that mistake would likely raise/crash/burn long before seeing, much less leaking sensitive data. > Having a nice at_fork hook would allow to safely disconnect the database in each forked process to avoid accidental file descriptor sharing between forks. > > Sequel: > https://github.com/jeremyevans/sequel/issues/691 I agree with Jeremy on this; it will likely cause new problems and surprises if libraries use it. > Passenger has PhusionPassenger.on_event(:starting_worker_process). > They give the example of memcached and by default use it to reestablish ActiveRecord connections: > https://www.phusionpassenger.com/library/indepth/ruby/spawn_methods/#unintentional-file-descriptor-sharing > > Puma has before_fork: > https://github.com/puma/puma/pull/754/files Exactly my point, everything relevant which forks has documented and supported means to disconnect/restart connections. > @normalperson Don't you think this deserves to be in core? Not anymore. > I would guess all of these do not work if rb_fork() is called. > What more motivation do we need? > Wait that a major incident happen due to unintentional fd > sharing because database libraries cannot protect themselves > from fork()? Again, this is a known problem with known workarounds for decades, now. I expect nobody has been able to get close to production or dealing with important data with such a broken setup. Unsubscribe: <mailto:[email protected]?subject=unsubscribe> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>