
On Tue, Dec 12, 2017 at 10:14 AM, Steven Boswell II via Boost-users
On Mon, Dec 12, 2017 at 7:42AM, Michael Powell via Boost-users
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.
Providing an allocator for pending socket operations involves having to provide the allocator in places where it's not feasible without forcing heavy changes on client code, e.g. asio_handler_allocate() and asio_handler_deallocate(). I can add a boost::asio::io_service<A> parameter to those 2 functions, but then they have to be templated too. Also, Boost::ASIO makes heavy use of typedefs that can't easily be made templated, not without requiring C++11's "using" feature.
It appears that Boost::ASIO won't work in an embedded context any time soon.
I spent a little time with it at the time, and if memory serves I was receiving segfault crashes. I didn't want to spend a lot of time persuading Boost/Asio, so I decided to go the RYO route.
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 agree, it's a pain, but it's not so bad. I got it working with a fairly simple byte level protocol, it was async as far as the app was concerned, running in a mutex guarded thread, and I managed to make it work for UDP as well as for TCP.
Thanks for your help.
-Steven
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users