我会对以下方面感兴趣:

最佳答案

范围

Boost.Asio是一个以网络为重点的 C++ 库，但其异步 I/O 功能已扩展到其他资源。此外，由于 Boost.Asio 是 Boost 库的一部分，它的范围略有缩小，以防止与其他 Boost 库重复。例如，Boost.Asio 不会提供线程抽象，如 Boost.Thread已经提供了一个。

另一方面，libuv是一个 C 库，旨在作为 Node.js 的平台层.它为 IOCP 提供了一个抽象。在 Windows 上，kqueue在 macOS 上，和 epoll在 Linux 上。此外，它的范围似乎略有增加，以包括抽象和功能，例如线程、线程池和线程间通信。

每个库的核心都提供事件循环和异步 I/O 功能。它们在一些基本功能上有重叠，例如定时器、套接字和异步操作。 libuv 的范围更广，并提供了额外的功能，例如线程和同步抽象、同步和异步文件系统操作、进程管理等。相比之下，Boost.Asio 的原始网络焦点表面，因为它提供了一组更丰富的网络相关功能，例如 ICMP、SSL、同步阻塞和非阻塞操作，以及用于常见任务的更高级别的操作，包括从流中读取直到接收到换行符。

功能列表

以下是一些主要功能的简要并排比较。由于使用 Boost.Asio 的开发人员通常有其他可用的 Boost 库，因此我选择考虑额外的 Boost 库，如果它们是直接提供的或实现起来很简单的话。

                         libuv          Boost
Event Loop:              yes            Asio
Threadpool:              yes            Asio + Threads
Threading:              
  Threads:               yes            Threads
  Synchronization:       yes            Threads
File System Operations:
  Synchronous:           yes            FileSystem
  Asynchronous:          yes            Asio + Filesystem
Timers:                  yes            Asio
Scatter/Gather I/O[1]:    no             Asio
Networking:
  ICMP:                  no             Asio
  DNS Resolution:        async-only     Asio
  SSL:                   no             Asio
  TCP:                   async-only     Asio
  UDP:                   async-only     Asio
Signal:
  Handling:              yes            Asio
  Sending:               yes            no
IPC:
  UNIX Domain Sockets:   yes            Asio
  Windows Named Pipe:    yes            Asio
Process Management:
  Detaching:             yes            Process
  I/O Pipe:              yes            Process
  Spawning:              yes            Process
System Queries:
  CPU:                   yes            no
  Network Interface:     yes            no
Serial Ports:            no             yes
TTY:                     yes            no
Shared Library Loading:  yes            Extension[2]

_{1. Scatter/Gather I/O.}

_{2. Boost.Extension was never submitted for review to Boost. As noted here, the author considers it to be complete.}

Event Loop

While both libuv and Boost.Asio provide event loops, there are some subtle differences between the two:

• While libuv supports multiple event loops, it does not support running the same loop from multiple threads. For this reason, care needs to be taken when using the default loop (uv_default_loop()), rather than creating a new loop (uv_loop_new()), as another component may be running the default loop.
• Boost.Asio does not have the notion of a default loop; all io_service are their own loops that allow for multiple threads to run. To support this Boost.Asio performs internal locking at the cost of some performance. Boost.Asio's revision history indicates that there have been several performance improvements to minimize the locking.

Threadpool

• libuv's provides a threadpool through uv_queue_work. The threadpool size is configurable via the environment variable UV_THREADPOOL_SIZE. The work will be executed outside of the event loop and within the threadpool. Once the work is completed, the completion handler will be queued to run within the event loop.
• While Boost.Asio does not provide a threadpool, the io_service can easily function as one as a result of io_service allowing multiple threads to invoke run. This places the responsibility of thread management and behavior to the user, as can be seen in this example.

Threading and Synchronization

• libuv provides an abstraction to threads and synchronization types.
• Boost.Thread provides a thread and synchronization types. Many of these types follow closely to the C++11 standard, but also provide some extensions. As a result of Boost.Asio allowing multiple threads to run a single event loop, it provides strands as a means to create a sequential invocation of event handlers without using explicit locking mechanisms.

File System Operations

• libuv provides an abstraction to many file system operations. There is one function per operation, and each operation can either be synchronous blocking or asynchronous. If a callback is provided, then the operation will be executed asynchronously within an internal threadpool. If a callback is not provided, then the call will be synchronous blocking.
• Boost.Filesystem provides synchronous blocking calls for many file system operations. These can be combined with Boost.Asio and a threadpool to create asynchronous file system operations.

Networking

• libuv supports asynchronous operations on UDP and TCP sockets, as well as DNS resolution. Application developers should be aware that the underlying file descriptors are set to non-blocking. Therefore, native synchronous operations should check return values and errno for EAGAIN or EWOULDBLOCK.
• Boost.Asio is a bit more rich in its networking support. In addition many of the features libuv's networking provides, Boost.Asio supporting SSL and ICMP sockets. Furthermore, Boost.Asio provides synchronous blocking and synchronous non-blocking operations, into addition to its asynchronous operations. There are numerous free standing functions that provide common higher-level operations, such as reading a set amount of bytes, or until a specified delimiter character is read.

Signal

• libuv provides an abstraction kill and signal handling with its uv_signal_t type and uv_signal_* operations.
• Boost.Asio does not provde an abstraction to kill, but its signal_set provides signal handling.

IPC

• libuv abstracts Unix domain sockets and Windows named pipes through a single uv_pipe_t type.
• Boost.Asio separates the two into local::stream_protocol::socket or local::datagram_protocol::socket, and windows::stream_handle.

API Differences

While the APIs are different based on the language alone, here are a few key differences:

Operation and Handler Association

Within Boost.Asio, there is a one-to-one mapping between an operation and a handler. For instance, each async_write operation will invoke the WriteHandler once. This is true for many of libuv operations and handlers. However, libuv's uv_async_send supports a many-to-one mapping. Multiple uv_async_send calls may result in the uv_async_cb being called once.

Call Chains vs. Watcher Loops

When dealing with task, such as reading from a stream/UDP, handling signals, or waiting on timers, Boost.Asio's asynchronous call chains are a bit more explicit. With libuv, a watcher is created to designate interests in a particular event. A loop is then started for the watcher, where a callback is provided. Upon receiving the event of interests, the callback will be invoked. On the other hand, Boost.Asio requires an operation to be issued each time the application is interested in handling the event.

To help illustrate this difference, here is an asynchronous read loop with Boost.Asio, where the async_receive call will be issued multiple times:

void start()
{
  socket.async_receive( buffer, handle_read ); ----.
}                                                  |
    .----------------------------------------------'
    |      .---------------------------------------.
    V      V                                       |
void handle_read( ... )                            |
{                                                  |
  std::cout << "got data" << std::endl;            |
  socket.async_receive( buffer, handle_read );   --'
}    

uv_read_start( socket, alloc_buffer, handle_read ); --.
                                                      |
    .-------------------------------------------------'
    |
    V
void handle_read( ... )
{
  fprintf( stdout, "got data\n" );
}

关于c++ - libuv 与 Boost/ASIO 相比如何？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11423426/