We would like to do type matching on the VRegId. Extracting the VRegID
from a usize makes the code a bit easier to understand and refactor.
MemBase uses a VReg, and there is also a VReg in Opnd. We should be
sharing types between these two, so this is a step in the direction of
sharing a type
Continually locking a mutex m can lead to starvation if all other threads are on the waitq of m.
See https://bugs.ruby-lang.org/issues/21840 for more details.
Solution:
When a thread `T1` wakes up `T2` during mutex unlock but `T1` or any other thread successfully acquires it
before `T2`, then we record the `running_time` of the thread during mutex acquisition. Then during unlock, if
that thread's running_time is less than the saved running time, we set it back to the saved time.
Fixes [Bug #21840]
It relies too much on VM level concerns, such that it can't be built
with modular GC enabled.
We'll move it into the VM, and then expose it to the GC
implementations so they can use it.
timer_thread_check_exceed() was returning true when the remaining time
was less than 1ms, treating it as "too short time". This caused
sub-millisecond sleeps (like sleep(0.0001)) to return immediately
instead of actually sleeping.
The fix removes this optimization that was incorrectly short-circuiting
short sleep durations. Now the timeout is only considered exceeded when
the actual deadline has passed.
Note: There's still a separate performance issue where MN_THREADS mode
is slower for sub-millisecond sleeps due to the timer thread using
millisecond-resolution polling. This will require a separate fix to
use sub-millisecond timeouts in kqueue/epoll.
[Bug #21836]
This reverts commit 23f9a0d655c4d405bb2397a147a1523436205486, "win32:
Strip CR from batch files", and add CR to the other batch files too.
`cmd.exe` seems to work well with LF at a glance, but sometimes `goto`
jumps to an unexpected line. This is probably because it is looking
for the beginning of a line, assuming that all lines end with CRLF,
and as a result mistaking the `goto` operand for a label.
- ### Problem
If you have a `version` in your config file (this feature was
introduced in #6817), then running any `bundle` command will
make Bundler re-exec and ultimately run the `bundle` binstub twice.
### Details
When the `bundle` binstub gets executed, a `require "bundler"` is
evaluated. RubyGems tries to require the `bundler.rb` file from
the right `bundler` gem (in the event where you have multiple
bundler versions in your system).
RubyGems will prioritize a bundler version based on a few
heurisitics.
b50c40c92a/lib/rubygems/bundler_version_finder.rb (L19-L21)
This prioritize logic doesn't take into account the bundler version
a user has specific in this config. So what happens is:
1. User execute the `bundle` binstub
2. `require 'bundler'` is evaluated.
3. RubyGems prioritize activating the bundler version specified
in the Gemfile.lock
4. The CLI starts, and [Auto switch kicks in](b50c40c92a/bundler/lib/bundler/cli.rb (L81)). Bundler detects that
user specifed a version in its config and the current Bundler
version doesn't match.
5. Bundler exit and re-exec with the right bundler version.
### Solution
This patch introduce two fixes. First, it reads the bundler config
file and check for the local config first and then the global
config. This is because the local has precedence over global.
Second, the prioritization takes into account the version in config
and let RubyGems activate the right version in order to prevent
re-exec moments later.
Finally, I also want to fix this problem because its a step toward
fixing https://github.com/ruby/rubygems/issues/8106. I'll open
a follow up patch to explain.
https://github.com/ruby/rubygems/commit/d6e0f43133
- Fix https://github.com/ruby/rubygems/issues/9238
- ### Problem
This is an issue that bites gem maintainers from time to time, with
the most recent one in https://github.com/minitest/minitest/issues/1040#issuecomment-3679370619
The issue is summarized as follow:
1) A gem "X" has a feature in "lib/feature.rb"
2) Maintainer wants to extract this feature into its own gem "Y"
3) Maintainer cut a release of X without that new feature.
4) Users install the new version of X and also install the new
gem "Y" since the feature is now extracted.
5) When a call to "require 'feature'" is encountered, RG will
fail to load the right gem, resulting in a `LoadError`.
### Details
Now that we have two gems (old version of X and new gem Y) with
the same path, RubyGems will detect that `feature.rb` can be loaded
from the old version of X, but if the new version of X had already
been loaded, then RubyGems will raise due to versions conflicting.
```ruby
require 'x' # Loads the new version of X without the feature which was extracted.
require 'feature' # Rubygems see that the old version of X include that file and tries to activate the spec.
```
### Solution
I propose that RubyGems fallback to a spec that's not yet loaded.
We try to find a spec by its path and filter it out in case a spec
with the same name has already been loaded.
Its worth to note that RubyGems already has a
`find_inactive_by_path` but we can't use it. This method only checks
if the spec object is active and doesn't look if other spec with the
same name have been loaded. The new method we are introducing
verifies this.
https://github.com/ruby/rubygems/commit/f298e2c68e
Timeout with 0-valued timespec means try to get an event, but return
immediately if there is none. Apparently timespec can have other
members, so best to 0 it out in that case.
If an exception is raised by the SSLContext#servername_cb proc, the
handshake should be canceled by sending an "unrecognized_name" alert to
the client, and the exception should be re-raised from SSLSocket#accept.
Add more direct assertions to confirm these behaviors.
https://github.com/ruby/openssl/commit/ac8df7f30f
The errno reported in an OpenSSL::SSL::SSLError raised by
SSLSocket#accept and #connect sometimes does not match what SSL_accept()
or SSL_connect() actually encountered. Depending on the evaluation order
of arguments passed to ossl_raise(), errno may be overwritten by
peeraddr_ip_str().
While we could just fix peeraddr_ip_str(), we should avoid passing
around errno since it is error-prone. Replace rb_sys_fail() and
rb_io_{maybe_,}wait_{read,writ}able() with equivalents that do not read
errno.
https://github.com/ruby/openssl/commit/bfc7df860f
