[Serialization] support AbstractLock and GenericCondition #43325
Conversation
Locks should be unlocked when serialized, and GenericCondition should drop their waiters. Otherwise, we may try to serialize a running Task (the user should normally be holding the lock around the data they are intending to serialize), which will fail and error.
| function deserialize(s::AbstractSerializer, ::Type{T}) where T<:Base.AbstractLock | ||
| lock = T() |
There was a problem hiding this comment.
This assumes that all fields of an AbstractLock are lock states, right? I think it's conceivable to have locks with parameters (e.g., back-off delays), and these values have to be serialized. Maybe we can serialize only const fields? It's somewhat too magical but kinda cool too.
In a long run, it'd be nice to have a Serialization API to declare the part of the value that shouldn't be serialized. I needed a rather ugly hack to avoid serialization of process-local scratch space:
https://github.com/JuliaFolds/FLoops.jl/blob/255382d84c187ec10521c0166412e5dfb213471b/src/scratchspace.jl#L45-L48 I don't think we need to solve it here but AbstractLock sounds like a good case study.
There was a problem hiding this comment.
Talked to Jeff, and we discussed how this is better than the current situation, and if someone needs something fancier, they can still implement that.
There was a problem hiding this comment.
Yes, I agree this PR is an improvement overall.
|
Should we revert this Future copy on serialization once this is merged? julia/stdlib/Distributed/src/remotecall.jl Line 373 in 63f6294 |
tkf
added
multithreading
…43325) Locks should be unlocked when serialized, and GenericCondition should drop their waiters. Otherwise, we may try to serialize a running Task (the user should normally be holding the lock around the data they are intending to serialize), which will fail and error.
…43325) Locks should be unlocked when serialized, and GenericCondition should drop their waiters. Otherwise, we may try to serialize a running Task (the user should normally be holding the lock around the data they are intending to serialize), which will fail and error.
Locks should be unlocked when serialized, and GenericCondition should
drop their waiters.
Otherwise, we may try to serialize a running Task (the user should
normally be holding the lock around the data they are intending to
serialize), which will fail and error.
Discovered in trying to make #42339 work