itrofimow
itrofimow
I feel like `NonFifo` is very unclear in terms of what a queue actually represents and leaves too wide of a room for an interpretation: stack is `NonFifo`, dequeing random...
There exists https://github.com/cameron314/readerwriterqueue, which might be a better fit for `concurrent::SpscQueue` – it has to be faster than full-featured `moodycamel::ConcurrentQueue` and it should also require less memory. There is some...
Due to `moodycamel::ConcurrentQueue` implementation details `engine::Yield` doesn't actually yield running thread back to the thread-pool: since moodycamel consists of a set of thread-local FIFO queues and every consumer checks for...
Addresses https://github.com/userver-framework/userver/issues/44
You see, `moodycamel::BlockingConcurrentQueue` spins [here](https://github.com/userver-framework/userver/blob/develop/third_party/moodycamel/include/moodycamel/blockingconcurrentqueue.h#L267) before going to kernel semaphore and although it's preferable for maximum throughput in benchmarks, it wastes CPU cycles in some real-life scenarios. Since [this commit](https://github.com/cameron314/concurrentqueue/commit/790db30df598bb45fdc63b571847160a2f9eb60b)...
There are some situations when a resource is accessed concurrently, but concurrency factor is limited by 2, - implications of socket r/w duality come to mind, - and `engine::Mutex` seems...
Deadline is only checked if a socket would block and some waiting should be performed, however it's completely possible for read/write to go through without blocking. One could expect that...
First of all, thank you guys for this impressive peace of software. As stated in the title, i'm a bit concerned about the lack of **comparison** benchmarks: guess its safe...
The described bug seems to be fixed by https://github.com/boostorg/lockfree/commit/df78b9da42d7f5124a865345759d86e95ea79823, which is in 1.74 and above