Porting from libevent to boost::asio: what is a direct equivalent of libevent's event in ASIO?

Question

I'm trying to backport a libevent-based library to use ASIO backend (thus avoid multiple event loops in single application). There are other ways to solve the "problem", but I'm interested in this one

I don't see a direct equivalent of event object (or, rather, a handle - because libevent is written in plain C) in Boost::ASIO documentation; boost::asio::strand looks familiar, but it doesn't seem to follow libevent's pattern: create, expect, receive, do work {, repeat }.

What I need is to have a set of object / event / event callback, which can be created and forgotten unless callback (by socket event) happens, running on top of io_service's loop; is there anything like that in Boost?

Answer 1

Boost.Asio does not provide an equivalent to the libevent's events.

In Boost.Asio, one creates an I/O object, such as a socket (1). The program will then initiate an operation, such as socket.async_receive(buffer, &handler) (2) to indicate that it wants data to be read from the socket into buffer, and invoke handler after data has been read. This step is similar to creating a non-persistent pending event in libevent, but one key difference is that Boost.Asio's Proactor will read data from the socket into buffer on behalf of the user, rather than informing the user that data is available to be read. Finally, Boost.Asio will forward the request to the operating system (3).

The operation system will then notify the io_service that data is available to read (4) in a similar fashion to when a libevent event becomes active. At some point, the application will process the event loop via io_service::run() (5), just like one would do with libevent's event_base_loop(). As data is available to be read, Boost.Asio will read data from the socket into buffer, then post user's callback (handler) into a queue of callbacks ready to invoked (6). The application will then invoke the callback while processing the event loop.

Boost.Asio puts a strong focus on the I/O object rather than the operations:

• An operation must be initiated each time the application is interested in handling an event on an I/O object. In this regard, the overall flow would be akin to a libevent program only using non-persistent events.
• Operations are not identifiable. Boost.Asio does not provide the same level of control that libevent provides for operations. For example, if an application has a pending read event and pending write event on a socket, libevent allows the write event to be removed via event_free() without affecting the read event. On the other hand, with operations not being identifiable in Boost.Asio, one can only cancel all pending operations, such as via socket.cancel(), rather than being able to cancel a specific operation, such as a write but not a read.

---

_{Source images and general details can located here.}