On Thu, 2 Apr 2020 at 00:48, Gavin Lambert via Boost-users < boost-users@lists.boost.org> wrote:

On 2/04/2020 07:27, Richard Hodges wrote:

...

On Wed, 1 Apr 2020 at 16:11, Stanislav Zaikin wrote:

Hello!

I have a custom network stack (it processed packets in userspace) which exposed some functions in C. It has its own listen, bind, accept functions and many other, and furthermore even custom epoll, select and poll.

I want to expand asio in some away, just to support my application with this custom network stack. But I'm a bit confused how I can do it.

Boost.Beast implements some custom stream types. That is, objects that model AsyncReadStream and AsyncWriteStream.

This would be a good place to start looking for examples.

There is also a primer on writing asio operations in the beast documentation.

That might suffice for custom listen/bind/accept/read/write.

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.

(There's also the question of whether you want to completely replace Asio's standard reactor or if you want to have something like a gateway thread that marshals work between your custom reactor and the standard reactor. Each has different tradeoffs.)

Jeff is probably correct that if you have questions about this you should ask directly on the Asio lists. The primary author doesn't read this list. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

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.