Re: [Boost-users] (Newbie) Embedded programming, memory pools, and allocate_shared()

Subject: Re: [Boost-users] (Newbie) Embedded programming, memory pools, and allocate_shared()
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-12-13 00:50:21

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.