* vm_args.c: rb_ary_dup(args->rest) to be used at most once during
parameter setup. [Feature #15010]
A patch by chopraanmol1 (Anmol Chopra) <chopraanmol1@gmail.com>.
* array.c (rb_ary_behead): added to remove first n elements.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64583 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
[ruby-core:88699][Bug #15035]
This patch was provided by MSP-Greg.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64582 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
`acquired' was an old boolean variable, but nowadays it is a
rb_thread_t pointer; "gvl.owner" seems like a more appropriate
name. And document the contended path including waitq, timer,
and timer_err.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64581 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Oddly, all existing test cases passed multiple times
before this patch (even with --jit-wait), so this seems
like a difficult failure to prove.
Fixes: r64576 ("process.c: simplify SIGCHLD-based waitpid")
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64577 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Introduce a new rb_thread_sleep_interruptible that does not
execute interrupts before sleeping. Skipping the interrupt
check before sleep is required for out-of-GVL ruby_waitpid_all
to function properly when setting waitpid_state.ret
Now that ubf_select can be called by the gvl.timer thread
without recursive locking gvl.lock, we can safely use
rb_threadptr_interrupt to deal with waking up sleeping
processes,
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64576 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This simplifies the locking logic somewhat.
While we're at it, designate_timer_thread is worthless in
ubf_select because gvl_acquire_common already guarantees there
is a gvl.timer if gvl->waitq is populated.
In the future (for auto-fiber), this will allow using
th->unblock.func for rb_waitpid callers (via rb_sigchld_handler).
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64575 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* To be able to run spec/ruby/command_line/dash_encoding_spec.rb
with the in-repo build.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64567 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The logic around blocking_region_begin is confusing to me,
but the goal of this patch is to ensure rb_sigwait_fd_get
and rb_sigwait_fd_put are matched.
In other words, we don't want a thread to hold sigwait_fd
forever if an exception is raised while calling select()
or ppoll().
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64550 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Arch Linux CI still seems to timeout on this test...
Note, I can't reproduce the failures in these tests on a
FreeBSD 11.1 VM while infinite-looping, even without the
"th.join(0.001)". It doesn't seem related to the use of
rb_wait_for_single_fd (r64529).
cf. https://rubyci.org/logs/rubyci.s3.amazonaws.com/arch/ruby-trunk/log/20180826T090003Z.fail.html.gz
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64543 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This let us avoid looping in rb_szqueue_max_set, saves us
some lines of code and reduces binary size slightly
(numbers from 32-bit x86):
text data bss dec hex filename
before: 91272 392 156 91820 166ac thread.o
after: 91200 392 156 91748 16664 thread.o
Inspiration from this taken from the FUTEX_WAKE op
of the Linux futex(2) syscall.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64542 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
It is identical to do_waitpid, and the win32 version will not
be needed for MJIT (since win32 does not suffer from the
waitpid(-1, ...) conflict where waits can get stolen.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64541 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
We need to ensure Signal.trap handlers can function if the main
thread is sleeping after a subthread has grabbed sigwait_fd,
but later exited.
Consider the following timeline:
main_thread sub-thread
-----------------------------------------
Signal.trap() { ... }
get sigwait_fd
ppoll on sigwait_fd
native_cond_sleep
(via pthread_cond_wait)
ppoll times-out
put sigwait_fd
sub-thread exits
only thread alive
SIGNAL HITS
The problem is pthread_cond_wait cannot return EINTR,
so we can never run the Signal.trap handler. So we
will avoid using native_cond_sleep in the main thread
and always use ppoll to sleep when in the main thread.
This can guarantee the main thread remains aware of
signals; even if it cannot safely read off sigwait_fd
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64538 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I updated the patch with documentation but forgot about it,
earlier :x
[ruby-core:88616] [Misc #15014]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64535 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Relying on "struct timespec" was too annoying API-wise and
used more stack space. "double" was a bit wacky w.r.t rounding
in the past, so now we'll switch to using a 64-bit type.
Unsigned 64-bit integer is able to give us over nearly 585
years of range with nanoseconds. This range is good enough
for the Linux kernel internal time representation, so it
ought to be good enough for us.
This reduces the stack usage of functions while GVL is held
(and thus subject to marking) on x86-64 Linux (with ppoll):
rb_wait_for_single_fd 120 => 104
do_select 120 => 88
[ruby-core:88582] [Misc #15014]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64533 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Closing a listen socket while entering select(2) may
trigger IOError or even deadlock because another thread
may give the file descriptor to another file description;
meaning the kernel can wait on the wrong description.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64532 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
IO#close is idempotent, so we don't need to waste bytecode
to check or nil it at shutdown time.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64531 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
IO#sysread calls rb_wait_for_single_fd for compatibility, and
perhaps something is amiss with that (unrelated to timer-thread
elimination)
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64529 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Based on r64478, any regular user creating more than 1024 pipes
on Linux will end up with tiny pipes with only a single page
capacity. So avoid wasting user resources and use lighter
eventfd on Linux.
[ruby-core:88563] [Misc #15011]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64527 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
ko1
hsbt
normal
eregon
svn
nobu
naruse