You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have already found a few hard to debug issues because of re-entrant locks in the wallet. This happens when one thread calls RwLock::read one time, and then calls it again without dropping the first handle. This operation will succeed as long as there are no writers waiting for the lock (on Linux, this behavior may change in other platforms).
The simplest solution would be to replace the RwLock with a variant that panics on re-entry. This way we would convert the deadlocks into panics. Unfortunately I don't known of any library that provides something like that, so we would need to do a quick assessment.
The other solution would be to re-think the architecture of the wallet so that the RwLock is not needed, this way we would avoid the problem of deadlocks entirely.
The text was updated successfully, but these errors were encountered:
We have already found a few hard to debug issues because of re-entrant locks in the wallet. This happens when one thread calls
RwLock::read
one time, and then calls it again without dropping the first handle. This operation will succeed as long as there are no writers waiting for the lock (on Linux, this behavior may change in other platforms).The simplest solution would be to replace the
RwLock
with a variant that panics on re-entry. This way we would convert the deadlocks into panics. Unfortunately I don't known of any library that provides something like that, so we would need to do a quick assessment.The other solution would be to re-think the architecture of the wallet so that the
RwLock
is not needed, this way we would avoid the problem of deadlocks entirely.The text was updated successfully, but these errors were encountered: