On 13/12/2017 04:14, Steven Boswell II wrote:
On Mon, Dec 12, 2017 at 7:42AM, Michael Powell wrote:
I considered Boost.Asio once upon a time for one of my embedded projects a couple of years ago, but I couldn't get it to work quite right, so I decided to roll my own messaging framework.
Sadly, that's the direction I'll probably have to go. [...] It appears that Boost::ASIO won't work in an embedded context any time soon.
It's too bad -- my upcoming project is going to make heavy use of asynchronous I/O, circular-buffers, and lock-free queues, and I really didn't want to have to roll my own. I hate reinventing the wheel; I have enough to do as it is.
I ended up rolling my own code for asynchronous serial I/O at one point because ASIO was a little too mutex-happy, which was causing latency issues. Although conversely my version was probably more malloc-happy than ASIO is. (And it used boost::function rather than templating all the things, which is probably another performance negative, albeit one that didn't matter as much to the application at hand.) But most memory allocators are decently fast nowadays, to the point where having memory allocations on threads that are doing socket I/O will probably be dominated by the I/O rather than the allocation. You just need to make sure that you're using a good per-thread allocator and keep the I/O on separate threads from anything that needs to be more realtime, and then you should be ok even if ASIO does allocate.