-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Lockable
to Base?
#52897
Comments
Kind of similar to #34400 I don't remember why we ended up closing that one. |
Ah yes, identical! 😄. I can only find one place to use this in base currently ( |
vtjnash
pushed a commit
that referenced
this issue
Feb 12, 2024
I am not sure about a `lock(f, ::Lockable)` method: it is nice because it unpacks the value for you, but it is weird because it unpacks the value for you. For a `Lockable`, `f` must accept one argument, whereas for a `Lock`, `f` must be 0-arg. A `Lockable` is not `<:AbstractLock` here, so maybe this is allowed, but if we deleted this `lock` method, we could inherit from `AbstractLock` and just use the generic one (requiring folks to unpack the value within the locked region themselves, as is the case for `@lock`). I think it is preferred these days to use `@lock` anyway, so having the `lock(f, ::Lockable)` method may be of limited value anyway. I searched Base and came up with two places that could currently use this internally, `TEMP_CLEANUP` and `env_dict`. We didn't add them both as usages yet, to avoid external breakage from delaying this PR. Similarly, this is not exported yet, to avoid breakage with older releases of ConcurrentUtilities.jl. redo of #34400 First commit copied from https://github.com/JuliaServices/ConcurrentUtilities.jl/blob/main/src/lockable.jl, Closes #52897 Co-authored-by: Jacob Quinn <quinn.jacobd@gmail.com> Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
e.g. like
as in https://github.com/JuliaServices/ConcurrentUtilities.jl/blob/main/src/lockable.jl.
I think this could be ergonomic for use in Base since there's various bits of global state that each need a lock (e.g. #49778), many of which are of the form
and one does
@lock(RESOURCE_LOCK, ...access RESOURCE...)
. WithLockable
, they could beand used by
@lock(RESOURCE, ...access RESOURCE[]...)
.By grouping the resource and it's lock into a struct, it makes it slightly harder to accidentally use the resource without the lock (since one needs to index into it), and it makes it crystal clear what lock is for what resource.
The text was updated successfully, but these errors were encountered: