To manage ractor-local data for C extension, the following APIs
are defined.
* rb_ractor_local_storage_value_newkey
* rb_ractor_local_storage_value
* rb_ractor_local_storage_value_set
* rb_ractor_local_storage_ptr_newkey
* rb_ractor_local_storage_ptr
* rb_ractor_local_storage_ptr_set
At first, you need to create a key of storage by
rb_ractor_local_(value|ptr)_newkey().
For ptr storage, it accepts the type of storage,
how to mark and how to free with ractor's lifetime.
rb_ractor_local_storage_value/set are used to access a VALUE
and rb_ractor_local_storage_ptr/set are used to access a pointer.
random.c uses this API.
Random generators are not Ractor-safe, so we need to prepare
per-ractor default random genearators. This patch set
`Random::DEFAULT = Randm` (not a Random instance, but the Random
class) and singleton methods like `Random.rand()` use a per-ractor
random generator.
[Feature #17322]
Added `WITH_REAL` versions to `RB_RANDOM_INTERFACE` macros. Also
these macros including "without real" versions no longer contain
the terminator (semicolon and comma).
* random.c: separate abstract rb_random_t and rb_random_mt_t for
Mersenne Twister implementation.
* include/ruby/random.h: the interface for extensions of Random
class.
* DLL imported symbol reference is not constant on Windows.
* check if properly initialized.
RARRAY_AREF has been a macro for reasons. We might not be able to
change that for public APIs, but why not relax the situation internally
to make it an inline function.
Saves comitters' daily life by avoid #include-ing everything from
internal.h to make each file do so instead. This would significantly
speed up incremental builds.
We take the following inclusion order in this changeset:
1. "ruby/config.h", where _GNU_SOURCE is defined (must be the very
first thing among everything).
2. RUBY_EXTCONF_H if any.
3. Standard C headers, sorted alphabetically.
4. Other system headers, maybe guarded by #ifdef
5. Everything else, sorted alphabetically.
Exceptions are those win32-related headers, which tend not be self-
containing (headers have inclusion order dependencies).
With these macros implemented we can write codes just like we can assume
the compiler being clang. MSC_VERSION_SINCE is defined to implement
those macros, but turned out to be handy for other places. The -fdeclspec
compiler flag is necessary for clang to properly handle __has_declspec().
Integer overflow for unsigned types are fully defined in C. They
are not always problematic (but not always OK). These functions
in this changeset intentionally utilizes that behaviour.
Blacklist from UBSAN checks for better output.
See also: 451624829
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65589 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
An instruction is leaf if it has no rb_funcall inside. In order to
check this property, we introduce stack canary which is a random
number collected at runtime. Stack top is always filled with this
number and checked for stack smashing operations, when VM_CHECK_MODE.
[GH-1947]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64677 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* random.c (fill_random_bytes_syscall): check if the version macro is
defined, for very old Mac OS X development tools.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64633 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
Some old implementaions of arc4random_buf(3) were ARC4 based, or
unsafe when forked, or both. Resort to /dev/urandom for those
known problematic cases. Fix [Bug #15039]
Patch from Thomas Hurst <tom@hur.st>
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64625 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* random.c (fill_random_bytes_syscall): use SecRandomCopyBytes in
Security framework on macOS 10.7 or later.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@64596 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
