[#88240] [Ruby trunk Feature#14759] [PATCH] set M_ARENA_MAX for glibc malloc — sam.saffron@...
Issue #14759 has been updated by sam.saffron (Sam Saffron).
[#88251] Re: [ruby-alerts:8236] failure alert on trunk@P895 (NG (r64134)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
[#88305] [Ruby trunk Bug#14968] [PATCH] io.c: make all pipes nonblocking by default — normalperson@...
Issue #14968 has been reported by normalperson (Eric Wong).
[#88331] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — samuel@...
Issue #13618 has been updated by ioquatix (Samuel Williams).
[#88342] [Ruby trunk Feature#14955] [PATCH] gc.c: use MADV_FREE to release most of the heap page body — ko1@...
Issue #14955 has been updated by ko1 (Koichi Sasada).
[#88433] [Ruby trunk Feature#13618] [PATCH] auto fiber schedule for rb_wait_for_single_fd and rb_waitpid — ko1@...
Issue #13618 has been updated by ko1 (Koichi Sasada).
ko1@atdot.net wrote:
[#88475] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — ko1@...
Issue #14937 has been updated by ko1 (Koichi Sasada).
[#88491] Re: [ruby-cvs:71466] k0kubun:r64374 (trunk): test_function.rb: skip running test — Eric Wong <normalperson@...>
k0kubun@ruby-lang.org wrote:
I see. Please remove the test if the test is unnecessary.
Takashi Kokubun <takashikkbn@gmail.com> wrote:
[#88523] [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed — eregontp@...
Issue #14999 has been updated by Eregon (Benoit Daloze).
eregontp@gmail.com wrote:
[#88549] [Ruby trunk Bug#14999] ConditionVariable doesn't reacquire the Mutex if Thread#kill-ed — eregontp@...
Issue #14999 has been updated by Eregon (Benoit Daloze).
[#88676] [Ruby trunk Misc#15014] thread.c: use rb_hrtime_scalar for high-resolution time operations — ko1@...
Issue #15014 has been updated by ko1 (Koichi Sasada).
ko1@atdot.net wrote:
On 2018/08/27 16:16, Eric Wong wrote:
[#88716] Re: [ruby-dev:43715] [Ruby 1.9 - Bug #595] Fiber ignores ensure clause — Eric Wong <normalperson@...>
Koichi Sasada wrote:
[#88723] [Ruby trunk Bug#15041] [PATCH] cont.c: set th->root_fiber to current fiber at fork — ko1@...
Issue #15041 has been updated by ko1 (Koichi Sasada).
[#88767] [Ruby trunk Bug#15050] GC after forking with fibers crashes — ko1@...
Issue #15050 has been updated by ko1 (Koichi Sasada).
Koichi Sasada <ko1@atdot.net> wrote:
[#88774] Re: [ruby-alerts:8955] failure alert on trunk@P895 (NG (r64594)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
[ruby-core:88603] [Ruby trunk Feature#15017] Provide extended information about Signal
Issue #15017 has been updated by nobu (Nobuyoshi Nakada).
shevegen (Robert A. Heiler) wrote:
> Some comments (personal opinion here):
>
> 1) I think the described use case is understandable, but if you can, I think it may
> help matz and the ruby core team decide on; for example, what is the specific API
> you had in mind? Could you give a more explicit code example here? You mentioned it
> here already: "additional param beside signal number for block" but I think it may
> help if you could give a specific example in ruby code, how it looks and perhaps
> an example sentence for documentation (may help whoever will write the code on the
> C level side, I think, and also provide an example to the on-line documentation
> for ruby+signal).
Currently, it is:
Signal.trap("INT") {|signo| }
where `signo` is an integer.
What I can think of is:
Signal.trap("INT") {|siginfo| }
where `siginfo` is an object which has `#to_int` method to return the signal number,
and other accessors.
Another idea is:
Signal.trap("INT") {signo, siginfo| }
but this can cause compatibility issues on the block arity.
> 2) I assume you use Linux, like many folks here do; matz uses debian as far as I
> know. I myself use mostly slackware, but compile literally almost everything from
> source using ruby scripts. Many other people use Windows, OSX/Mac variant or even
> less common operating systems (Solaris, the various BSD flavours, HaikuOS and so
> forth). There are examples where features have been rejected because they may
> only run on some systems but not others. I do not know whether this is the case
> in your example; perhaps there are agnostic implementations possible that would
> work on every platform. That would be best.
As far as rubyci.org, UNIX-like platforms have `sigaction` all, including AIX, FreeBSD, Solaris and macOS.
----------------------------------------
Feature #15017: Provide extended information about Signal
https://bugs.ruby-lang.org/issues/15017#change-73659
* Author: jreidinger (Josef Reidinger)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
----------------------------------------
Hi,
I see that ruby already use sigaction for signal handling on linux. It would be really nice to extend it to provide also signal details in siginfo_t and then provide such details in ruby via Signal module (as additional param beside signal number for block). Use case is quite simple. Our ruby application is killed by sigint and we do not know who send this signal. We already catching signal and logging as much as possible, but without siginfo we are very limited. We do not know ff it is OOMKiller due to low memory, systemd or something else. This additional info in siginfo allows us to log a much more details when such signal appear and inspect process that send us this signal. This is useful especially on customer side where we do not have direct control and we get only logs from failed run.
If you need more info or help with example usage, do not hesitate to ask.
Thanks
Josef
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>