Rarely, there are cases where a write(2) call from a child thread
to notify the main thread of the completion of name resolution fails.
If this happens while the main thread is waiting in `rb_thread_fd_select`,
rb_thread_fd_select may not notice that the name resolution has completed and end up hanging.
This issue becomes a problem when there are no sockets currently being connected,
no addresses ready for immediate connection attempts,
and name resolution has already completed for one address family
while the main thread is waiting for the name resolution of the other address family.
(If name resolution is not completed for either address family,
the chances of write(2) failing in both child threads are likely low.)
To avoid this issue, a timeout is introduced to rb_thread_fd_select under the above conditions.
This way, even if the issue occurs,
the completion of name resolution should still be detected
in the subsequent `if (!resolution_store.is_all_finished) ...` block.
Ruby's MEMMOVE takes in the element data type for the third argument, not
the size of the element. What this did was do sizeof(sizeof( ... )) which
always returned sizeof(size_t).
This change will be merged into 3.5 along with other encoding, command
line, environment variables, etc.
Revert following commits:
- bd831bcca534955533d9135d8c2f22d7ae5b9aa8
[Bug #20929] Win32: Use `wcsftime`
- 1c15f641cc2bb88fa88123a11036ed58fbf9aa6d
[Bug #20929] Win32: Encode timezone name in UTF-8
- 78762b52185aa80ee55c0d49b495aceed863dce2
[Bug #20929] Fix `assert_zone_encoding`
After a ractor is started (multi-ractor mode), any calls to
require_internal will hang the process due to deadlock. For example,
loading a new encoding will deadlock after a ractor starts.
Fixes [Bug #19562]
When a dedicated native thread fails to create (OS can't create more
threads), don't add the ruby-level thread to the thread scheduler. If
it's added, then next time the thread is scheduled to run it will sleep
forever, waiting for a native thread that doesn't exist to pick it up.
We need to GC guard the iseq because the code above it malloc memory which
could trigger a GC. Since we only use ISEQ_BODY, the compiler may optimize
out the iseq local variable so we need to GC guard it.
Fixes: http://ci.rvm.jp/results/trunk_asan@ruby-sp1/5484752
We must disable GC when running RUBY_INTERNAL_EVENT_NEWOBJ hooks because
the callback could call xmalloc which could potentially trigger a GC,
and a lot of code is unsafe to trigger a GC right after an object has
been allocated because they perform initialization for the object and
assume that the GC does not trigger before then.
