`Monitor` is about as useful as `Mutex` and yet one is a core class and the other is a "stdlib" extension. I propose to promote `Thread::Monitor` as a core class convenience. ### The rest of `monitor.rb` The `monitor` stdlib als...byroot (Jean Boussier)
> Can I be of any help? I rebased the PR, you can review the spec to see if the behavior make sense. As for merging I'm afraid it's a bit late now, but that's @hsbt's call I think.byroot (Jean Boussier)
This guard was removed in https://github.com/ruby/ruby/pull/13497 on the justification that some GC may need to be notified even for immediate. But the two currently available GCs don't, and there are plenty of assumtions GCs don't ever...byroot (Jean Boussier)
> Regarding to power_assert So it's great power_assert has much more advanced parsing capabilities, but I for one would use the column information for things like Rails' `assert_difference -> { User.count }, +1`, as it would be quite ...byroot (Jean Boussier)
Isn't `Proc.source_location` very useful for things akin to `power_assert`? If it was easy to extract a proc's source code I'd certainly integrate it in testing framework to improve failure rendering.byroot (Jean Boussier)
Maybe I'm totally off, but I expect this data to be used to extract the source code, e.g show a snippet of code in an error message, or something akin to that, hence byte offsets seem actually more convenient? (and performant). But ye...byroot (Jean Boussier)
Mutexes spend a significant amount of time in `rb_fiber_serial` because it can't be inlined (except with LTO). The fiber struct is opaque the so function can't be defined as inlineable. Ideally the while fiber struct would not be opaque...byroot (Jean Boussier)
So, if Monitor was made a core class, it could benefit from some optimizations and be almost as fast as Mutex: https://github.com/ruby/ruby/pull/15538 ``` ruby 4.0.0dev (2025-12-13T06:49:18Z core-monitor 6fabf389fd) +YJIT +PRISM [arm...byroot (Jean Boussier)