Thomas Rodgers

> Another modest plea to drop `memory.atomic.wait64` (f.k.a. `i64.atomic.wait`) for the sake of allowing a straightforward `futex()`-based implementation. An additional modest plea to ease the requirements of `memory.atomic.wait32` to allow...

Agree. On Monday, September 28, 2015, Andrey Upadyshev [email protected] wrote: > I propose to rename azmq::message's string() function into to_string(). > This approach consistent with STL naming (check bitset and...

This should be possible, let me do some digging.

dispatch() is probably the right thing to do here instead of post anyway. I'm putting together an update to azmq, I will include this change.

Agreed. On Friday, June 12, 2015, Andrey Upadyshev [email protected] wrote: > There few places where flag ZMQ_RCVMORE is passed to function zmq_msg_recv > where it should has no meaning (see...

You are correct, azmq::actor::spawn is something entirely different from Asio's stackful coroutines. They are equivalent to czmq's actors. I have an experimental 'typed actor' implementation (similar to Akka's typed actors)...

Chris Kohlhoff (Asio's author) is well aware of these issues. He has presented a couple of papers to SG1 (C++ Standards Committee concurrency study group) about the performance of callbacks...

Is there any chance I could get a minimal reproduction case?

I can confirm with Chris Kohlhoff, but I was thinking of just making 1.56 the base Boost required version unless there is a compelling reason not to. On Sunday, November...

Chris confirms 1.54 introduced std::future support. I'm happy to make that the minimum version if there is a compelling reason. On Sunday, November 23, 2014, Thomas Rodgers [email protected] wrote: >...