Context: https://github.com/ivoanjo/gvl-tracing/pull/4
Some hooks may want to collect data on a per thread basis.
Right now the only way to identify the concerned thread is to
use `rb_nativethread_self()` or similar, but even then because
of the thread cache or MaNy, two distinct Ruby threads may report
the same native thread id.
By passing `thread->self`, hooks can use it as a key to store
the metadata.
NB: Most hooks are executed outside the GVL, so such data collection
need to use a thread-safe data-structure, and shouldn't use the
reference in other ways from inside the hook.
They must also either pin that value or handle compaction.
Follow up https://github.com/ruby/bigdecimal/issues/89.
`BigDecimal.new` has already been removed. This PR replaces `BigDecimal.new` with
`Kernel.BigDecimal` in the documentation, following the message below:
> BigDecimal.new is deprecated; use Kernel.BigDecimal method instead.
26d84ba766dd52adf3b2
After a pthread for getaddrinfo is detached, we cannot predict when the
thread will exit. It would lead to a segfault by setting
pthread_setaffinity to the terminated pthread. I guess this problem
would be more likely to occur in high-load environments.
This change detaches the pthread after pthread_setaffinity is called.
[Feature #19965]
Add a new API rb_profile_thread_frames(), which is essentialy a
per-thread version of rb_profile_frames().
While the original rb_profile_frames() always returns results about the
current active thread obtained by GET_EC(), this new API takes a Thread
to be profiled as an argument.
This should come in handy when profiling I/O-bound programs such as
webapps, since this new API allows us to learn about Threads performing
I/O (which do not have the GVL).
Profiling worker threads (such as Sidekiq workers) may be another
application.
Implements [Feature #10602]
Co-authored-by: Mike Perham <mike@perham.net>
extconf.rb
(https://github.com/ruby/zlib/pull/69)
The android NDK (android-ndk-r21e) does not have crc32_z, adler32_z, nor
z_size_t in its zlib.h header file. However, it _does_ have the crc32_z
and adler32_z symbols in the libz.a static library!
mkmf performs two tests for have_func:
* It sees if a program that includes the header and takes the address of
the symbol can compile
* It sees if a program that defines the symbol as `extern void sym_name()`
and calls it can be linked
If either test works, it considers the function present. The
android-ndk-r21e is passing the second test but not the first for
crc32_z/adler32_z. So, we define HAVE_ZLIB_SIZE_T_FUNCS, but then can't
actually compile the extension (since the prototypes aren't in the
header file).
We can keep this working how it was working before by _also_ checking
for `have_type("z_size_t", "zlib.h")`. The have_type check _only_ looks
in the header file for the type; if a program including the header file
and using the type can't compile, the type is considered absent
regardless of what might be in libz.a.
3b9fe962d8
We use the Cloudflare fork of zlib
(https://github.com/cloudflare/zlib), which we find gives improved
performance on AWS Graviton ARM instances. That fork does not define
crc32_z and alder32_z functions.
Until two days ago, Ruby's zlib gem worked fine, because cloudflare zlib
_also_ did not define z_size_t, which meant Ruby did not try and use
these functions.
Since a3ba99596d
however, cloudflare zlib _does_ define z_size_t (but NOT crc32_z or
alder32_z). The zlib gem would try and use these nonexistant
functions and not compile.
This patch fixes it by actually specifically detecting the functions
that the gem wants to call, rather than just the presence of the
z_size_t type.
c96e8b9a57
When pthread_create is available, rb_getaddrinfo creates a pthread and
executes getaddrinfo(3) in it. The caller thread waits for the pthread
to complete, but detaches it if interrupted. This allows name resolution
to be interuppted by Timeout.timeout, etc. even if it takes a long time
(for example, when the DNS server does not respond). [Feature #19965]
