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 are using a lot of std::sync::Mutex in RawMaster and some other places, they are not never held long so they should not perturbate the async flow, however it is unclear what their locking/unlocking performance cost is.
we are using tokio::sync::Mutex in Group and in crates using etherage. they are meant to not perturbate the async flow, but their locking/unlocking cost can be high since they are relying on a std::sync::Mutex that is locked/unlocked at each poll.
to investigate
We should see if it is possible to replace both of them with a home-made async mutex implemented with atomics, so polling it would only be an atomic read
The text was updated successfully, but these errors were encountered:
At the moment
std::sync::Mutex
inRawMaster
and some other places, they are not never held long so they should not perturbate the async flow, however it is unclear what their locking/unlocking performance cost is.tokio::sync::Mutex
inGroup
and in crates usingetherage
. they are meant to not perturbate the async flow, but their locking/unlocking cost can be high since they are relying on astd::sync::Mutex
that is locked/unlocked at eachpoll
.to investigate
We should see if it is possible to replace both of them with a home-made async mutex implemented with atomics, so polling it would only be an atomic read
The text was updated successfully, but these errors were encountered: