boost asio serial_port_service和serial_port有什么区别 [英] What is the difference of boost asio serial_port_service and serial_port

问题描述

我实现（希望）鲁棒的异步串行rs232数据传输（通过USB） - 对于windows和linux，包括esp。

最后，我只想（可兼容地）讲话rs232与强烈的截止时间超时，cancel（）复位）等不崩溃/挂起，例如tx或rx线意外断开。所以，我可以简单地复制/粘贴/采纳现有的例子。但我也想变得更加开明; - ）

我决定使用 boost：asio :: serial_port 。现在在阅读文档的时候，我对这两个类感兴趣（三个用typedef serial_port）：

serial_port_service - 串口的默认服务实现。

  class serial_port_service：public io_service :: service 
  

basic_serial_port - 提供串行端口功能。

 模板< typename SerialPortService = serial_port_service> 
 class basic_serial_port：
 public basic_io_object< SerialPortService>，
 public serial_port_base 
  

很明显，我需要一个 boost :: asio :: io_service 构造 boost :: asio :: serial_port 或 serial_port_service 。
我想我已经了解asio如何做这项工作的基本方法，如在例如此示例。

OK serial_port_service 源自io_service，其ctor接受 io_service ，其接口也提供对于我来说，它看起来像是一个io_service，它也实现了一个basic_serial_port - 什么是原因是什么？具有两个类别？什么时候使用一个时候另一个？不确定可能的用例，以及这个 serial_port typedef。也许（很明显）我缺少的东西 - 有人可以给我更多的光？

解决方案

通常，应用程序应该使用I / O对象。在这种情况下，这将是 boost :: asio :: serial_port 。

---

用于分离职责和抽象。名称的相似性可能令人困惑，因此文档在其命名中非常小心。 文档 states：

类 io_service 实现了一个可扩展， I / O服务的多态集合，按服务类型索引。必须在可以使用I / O对象（如套接字，解析器和计时器）之前初始化 io_service 类的对象。这些I / O对象通过具有接受 io_service& 参数的构造函数来区分。

I / O服务存在以代表I / O对象管理操作系统的逻辑接口。特别地，存在跨一类I / O对象共享的资源。例如，可以根据单个定时器队列来实现定时器。

要在串行端口的上下文中解释这一点：

• io_service 提供了事件处理循环并管理I / O服务，例如 serial_port_service 。


• serial_port 是一个I / O对象，提供了一个接口来执行串行端口相关操作。实现是非常基本的：
  
  
  
  • 确定如何将信息返回给调用者：throw如果发生错误，则填充 std :: future ，暂停协程
  
  
  • 将实际工作导入到其I / O服务 serial_port_service 。
  
  
  • 提供 RAII 语义。当 serial_port 被销毁时，它将取消未完成的异步操作，并关闭 serial_port 。
  
  


• serial_port_service 是一个I / O服务：
  
  
  
  • 它提供了一个抽象并实现了平台特定的API。
  
  
  • 在 serial_port $ c> io_service 。当使用 io_service 创建 serial_port 时， serial_port 将使用注册到 io_service 的现有 serial_port_service 或创建并注册新的 serial_port_service 与 io_service 。
  
  
  • 用作I / O对象 实现 。对于 serial_port ，这可能是一个基本的文件描述符或句柄。
  
  



I am to implement a (hopefully) robust asynchronious serial rs232 data transmission (via USB) - for both windows and linux, including esp. that nice embedded system called beagle bone black.

In the end I just want to be able to (compatibly) talk rs232 with robust deadline-timeouts, cancel() reset() etc. to not crash/hang when e.g. the tx or rx line disconnects accidently. So sure, I could simply copy/paste/adopt existing examples. But I also would like to become more enlightened ;-)

I decided to use boost:asio::serial_port. Now while reading the docs, I am confused about this two classes (well three with the typedef serial_port):

serial_port_service - Default service implementation for a serial port.

class serial_port_service : public io_service::service

basic_serial_port - Provides serial port functionality.

template< typename SerialPortService = serial_port_service>
class basic_serial_port :
  public basic_io_object< SerialPortService >,
  public serial_port_base

So faar I see, that I need a boost::asio::io_service to construct either boost::asio::serial_port or serial_port_service. I think I have understand the basic approach how asio does the job, like bespoken in e.g. this examples .

OK serial_port_service derives from io_service, its ctor takes an io_service, and its interface also offers those memberfuncs of basic_serial_port.

For me it looks like it's a io_service that also implements a basic_serial_port - what is the reason for having both classes? When to use the one when the other? Not sure about possible usecases, and what about this serial_port typedef. Maybe (well obviously) I am missing something - someone can give me more light?

解决方案

Often, the application should use the I/O object. In this case, that would be boost::asio::serial_port.

---

The various classes are used to separate responsibilities and abstractions. The similarity in names can be confusing, so the documentation is very careful in its naming. The documentation states:

Class io_service implements an extensible, type-safe, polymorphic set of I/O services, indexed by service type. An object of class io_service must be initialised before I/O objects such as sockets, resolvers and timers can be used. These I/O objects are distinguished by having constructors that accept an io_service& parameter.

I/O services exist to manage the logical interface to the operating system on behalf of the I/O objects. In particular, there are resources that are shared across a class of I/O objects. For example, timers may be implemented in terms of a single timer queue. The I/O services manage these shared resources.

To explain this in context of serial ports:

• The io_service provides an event processing loop and manages I/O services, such as serial_port_service.
• The serial_port is an I/O object that provides an interface to perform serial port related operations. The implementation is very basic:
  • Determines how information is to be returned to the caller: throw if an error occurs, populate a std::future, suspend a coroutine, etc.
  • Defers the actual work to the serial_port_service, its I/O service.
  • Provides RAII semantics. When the serial_port is destroyed, it will cancel outstanding asynchronous operations and close the serial_port.
• The serial_port_service is an I/O service:
  • It provides an abstraction and implements the platform specific API.
  • It is shared amongst serial_ports that use the same io_service. When the serial_port is created with an io_service, the serial_port will use an existing serial_port_service registered to the io_service or create and register a new serial_port_service with the io_service.
  • It functions as an factory for an I/O object's implementation. For a serial_port, this is likely a basic file descriptor or handle.

这篇关于boost asio serial_port_service和serial_port有什么区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！