-
Notifications
You must be signed in to change notification settings - Fork 143
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
API Lock Preferences #1022
API Lock Preferences #1022
Conversation
This adds a bunch of complexity, and 2 additional runtime lookups at each call. Personally i don't think it's worth it (especially since I haven't been able to see any noticeable overhead with the locking). I think if you want to make it optional, just make it an all-or-nothing: const use_api_lock = @load_preference("use_api_lock", true) and make the API function wrappers: use_api_lock && lock(liblock)
var"#status#" = try
# ccall
finally
use_api_lock && unlock(liblock)
end
var"#status#" < 0 && @h5error ...
return nothing |
After testing, I am getting this error. I suspect this is because the finalizer is trying to run after we call Line 77 in af62ebf
|
Is there a reason why the tests call |
@@ -5,36 +5,36 @@ using Test, HDF5 | |||
|
|||
filename = joinpath(dirname, "main.hdf5") | |||
|
|||
f = h5open(filename, "w") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The issue was here. We forgot to close this handle explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably best to pull this into a different PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can pull this into a different pull request, but this needs to be here as well since CI will error otherwise.
@simonbyrne I simplified this along the lines of your #1022 (comment) . I think this will allow us to more easily diagnose any potential issues or regressions that might emerge from this. I also removed the RawAPI module. Something I would like to pay particular attention to is the use of the |
src/api/lock.jl
Outdated
the HDF5 C library is not thread-safe. Concurrent calls to the HDF5 library | ||
from multiple threads will likely fail. | ||
""" | ||
const use_api_lock = Preferences.@load_preference("use_api_lock", default = true) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const use_api_lock = Preferences.@load_preference("use_api_lock", default = true) | |
const use_api_lock::Bool = Preferences.@load_preference("use_api_lock", default = true) |
then the error below is not necessary
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My thinking here is that the error I wrote would be more descriptive than the following since this potentially faces an end user. I suppose I could try catch the MethodError though.
ERROR: MethodError: Cannot `convert` an object of type String to an object of type Bool
Closest candidates are:
convert(::Type{T}, ::Ptr) where T<:Integer at pointer.jl:23
convert(::Type{T}, ::T) where T<:Number at number.jl:6
convert(::Type{T}, ::Number) where T<:Number at number.jl:7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess? Seems like a bit of a weird error case to be worried about though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems a bit too easy for someone to edit their LocalPreferences.jl and accidentally quote true
. Maybe we need to add a tryparse
.
julia> convert(Bool, "true")
ERROR: MethodError: Cannot `convert` an object of type String to an object of type Bool
Closest candidates are:
convert(::Type{T}, ::Ptr) where T<:Integer at pointer.jl:23
convert(::Type{T}, ::T) where T<:Number at number.jl:6
convert(::Type{T}, ::Number) where T<:Number at number.jl:7
...
Stacktrace:
[1] top-level scope
@ REPL[65]:1
julia> tryparse(Bool, "true")
true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually the type assertion a global const will not work with Julia 1.6, and I think we're still trying to maintain compat with Julia 1.3
src/api/lock.jl
Outdated
const use_lock_and_close = | ||
Preferences.@load_preference("use_lock_and_close", default = true) && !use_api_lock |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use_lock_on_close
?
src/api/lock.jl
Outdated
@info "Please restart Julia for the use_api_lock preference to take effect" | ||
Preferences.@set_preferences!("use_api_lock" => use_api_lock) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe only print the message if it has changed?
I don't know, but it sure does help catch unclosed handles. |
Closing and resubmitting PR directly to master. |
This builds on the
sb/lock
branch by using Preferences.jl to configure the lock usage at compile time.The preference,
use_api_lock
can be set to eithertrue
orfalse
.The preference is set via the
API.set_use_lock_pref!
function and can be quered byAPI.get_use_lock_pref()
.This mainly meant to help assess the
sb/lock
branch.Other features such as the RawAPI module have been withdrawn.