On Fri, 3 Apr 2020 at 07:14, Gavin Lambert via Boost-users <boost-users@lists.boost.org> wrote: > > On 2/04/2020 11:57, Richard Hodges wrote: > > On Thu, 2 Apr 2020 at 00:48, Gavin Lambert wrote: > > But custom epoll/select/poll is an entirely different kettle of fish. > > If your custom library must use those (and cannot provide a standard > > platform file descriptor that works with the standard platform > > epoll/select/poll), then you're largely out of luck. For that, you > > would have to write a custom reactor instead; and as far as I am aware > > without deep modifications to Asio there is no provision for doing so > > (and it's a massive amount of work that is hard to get correct, > > although you can use the existing implementations as a guide). > > > > I respectfully disagree. You'd have to write a new executor and > > associated context. It would look very similar to the existing one. > > (Granted I was mostly thinking of pre-executor Asio when writing the > above, but...) > > Having recently had an adventure myself in implementing a custom > executor, I stand by my statement. > > There are many required operations it does not seem possible to > implement without either depending on or reimplementing 'detail' code > from Asio, and there is very little guidance on doing so. Unless you > know of some example...?
Most people who design systems with low-latency networking end up re-implementing their own executor framework. I suppose it could be useful if it could be done entirely with asio-compliant concepts. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
