Project

General

Profile

Actions

Feature #18256

open

Change the canonical name of Thread::Mutex, Thread::Queue, Thread::SizedQueue and Thread::ConditionVariable to just Mutex, Queue, SizedQueue and ConditionVariable

Added by Eregon (Benoit Daloze) about 3 years ago. Updated about 3 years ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:105672]

Description

Currently these 4 classes are defined as both constants of Object and of Thread.

On CRuby 3.0.2, their #inspect shows they were first defined under Thread and then aliased in Object:

$ ruby -ve 'p [Mutex, Queue, SizedQueue, ConditionVariable]'
ruby 3.0.2p107 (2021-07-07 revision 0db68f0233) [x86_64-linux]
[Thread::Mutex, Thread::Queue, Thread::SizedQueue, Thread::ConditionVariable]

FWIW this contrasts to TruffleRuby which has:

$ ruby -ve 'p [Mutex, Queue, SizedQueue, ConditionVariable]'
truffleruby 22.0.0-dev-589c944e, like ruby 2.7.4, GraalVM CE Native [x86_64-linux]
[Mutex, Queue, SizedQueue, ConditionVariable]

(because these classes are all core now and I thought the Thread:: prefix was the alias since they moved to core)

However I believe most usages out there do not use the Thread:: prefix, or in other words almost nobody uses the Thread:: prefix for those classes.
And it seems very clearly confirmed by gem-codesearch:

$ gem-codesearch 'Thread::Mutex' | wc -l
254
$ gem-codesearch '\bMutex\b' | wc -l
19378

About 75x more common to use Mutex than Thread::Mutex it seems.

$ gem-codesearch 'Thread::Queue' | wc -l
138
$ gem-codesearch '\bQueue\b' | wc -l
38174

About 276x more common to use Queue than Thread::Queue it seems.

$ gem-codesearch 'Thread::ConditionVariable' | wc -l
110
$ gem-codesearch '\bConditionVariable\b' | wc -l
2145

About 19.5x more common to use ConditionVariable than Thread::ConditionVariable it seems.

$ gem-codesearch 'Thread::SizedQueue' | wc -l
27
$ gem-codesearch '\bSizedQueue\b' | wc -l
633

About 23x more common to use SizedQueue than Thread::SizedQueue it seems.

So I propose to update the canonical names of these classes to be without the Thread:: prefix, to represent the vast majority of usages, and also the fact these classes are core now and not stdlib.
In other words, for 3.1.0 I propose:

$ ruby -ve 'p [Mutex, Queue, SizedQueue, ConditionVariable]'
ruby 3.1.0 ...
[Mutex, Queue, SizedQueue, ConditionVariable]

Updated by Eregon (Benoit Daloze) about 3 years ago

Related, there is this PR by nobu to make ruby/spec use the Thread:: prefix: https://github.com/ruby/spec/pull/867
I agree it makes sense to align the canonical name and specs hierarchy (although I think it's not too important either).
I think it's better to change the canonical name to what people use though, hence this proposal.

Actions #2

Updated by Eregon (Benoit Daloze) about 3 years ago

  • Description updated (diff)

Updated by nobu (Nobuyoshi Nakada) about 3 years ago

I’m against.
The current names have been moved from the top level, to make clarify the roles.

Updated by Eregon (Benoit Daloze) about 3 years ago

nobu (Nobuyoshi Nakada) wrote in #note-3:

The current names have been moved from the top level, to make clarify the roles.

I don't understand this reasoning. What else could a Mutex/Queue/SizedQueue/ConditionVariable be for if for threading-related things? There doesn't seem to be any other classes with the same names to disambiguate.
Could you or someone else expand on this?

There was some discussion about Fiber equivalents but I think we kind of settled on reusing the same classes and they should be Fiber-scheduler aware, because that's just so much more useful and practical for existing code (e.g., the Fiber scheduler is called when a Mutex cannot be acquired immediately for non-blocking fibers).

Maybe for Ractor? Ractor can add variants of those if needed, but it also seems clear Actor-like programming should probably avoid most of these abstractions anyway.

Also I don't see how the canonical name has any effect on these 60000+ usages, hence it seems needlessly long, and users clearly don't care about what the canonical name is.
It's also very clear we will never be able to remove or deprecate them in Object given the amount of usages.

Updated by znz (Kazuhiro NISHIYAMA) about 3 years ago

'\bMutex\b' counts Thread::Mutex too.

$ gem-codesearch '\bMutex\b' | grep Thread::Mutex | wc -l
254

Updated by Eregon (Benoit Daloze) about 3 years ago

znz (Kazuhiro NISHIYAMA) wrote in #note-5:

'\bMutex\b' counts Thread::Mutex too.

True, although given the proportion it doesn't really change things much.
gem-codesearch is always an approximation anyway.

Trying to be a little bit more precise:

$ gem-codesearch '([^:]|^|\s::)\bMutex\b' | wc -l
17969

It's still "overwhelmingly more than Thread::Mutex", which is used by extremely few gems.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0