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
The documentation on *_unsynchronized functions states that they are unsafe because they are 'unsynchronized'. However, they do not state what kind of synchronization the caller is expected to perform. Looking at the implementations of the safe variants, it seems that they all acquire a global lock. It is not obvious to me why this is necessary. See also #637, which appear to argue that it is not?
If locking is necessary, then I think this locking behavior should be documented on the safe functions, as it is a significant performance pitfall. I get that the main focus of this crate is to help with error diagnostics, where performance is probably not super important. I was planning to use it to implement a sampling profiler for bare-metal environments, and this would be pretty important to know.
The text was updated successfully, but these errors were encountered:
The documentation on
*_unsynchronized
functions states that they are unsafe because they are 'unsynchronized'. However, they do not state what kind of synchronization the caller is expected to perform. Looking at the implementations of the safe variants, it seems that they all acquire a global lock. It is not obvious to me why this is necessary. See also #637, which appear to argue that it is not?If locking is necessary, then I think this locking behavior should be documented on the safe functions, as it is a significant performance pitfall. I get that the main focus of this crate is to help with error diagnostics, where performance is probably not super important. I was planning to use it to implement a sampling profiler for bare-metal environments, and this would be pretty important to know.
The text was updated successfully, but these errors were encountered: