Should this be merged back to standard library?
umurgdk opened this issue · 2 comments
Since this is a more performant implementation of std::sync::Barrier, shouldn't this be in the standard library instead of a 3rd party library?
I asked the same question on rust forums.
There was some discussion about this over on reddit. I'll replicate my answer from there here for context:
Well, this barrier (at least in its current form) spins when waiting, which wouldn't be acceptable in the std lib. This is likely the right thing to do for applications that care about the latency of barrier synchronizations, since thread sleep/wakeup is pretty expensive, but is probably not the right primitive for everyone.
Having thought a little more about this, hurdles::Barrier could probably be modified so that it falls back to parking the thread (e.g., through a Mutex) after it has spun for a couple of times, but it's a bit of a tricky change.
A second reason why you probably wouldn't be able to move std to this Barrier is that std::sync::Barrier has an &self receiver and expects to be placed in an Arc, whereas hurdles::Barrier keeps mutable state for each barrier, and therefore uses &mut self and is Clone instead. I also (just now) posted that as a follow-up on your users.rlo post.