What's the difference in boost asio serial_port_service and serial_port
I have to implement a reliable rs232 asynchronous serial data transfer (over USB) (for reliable) - for both windows and Linux including esp. this wonderful embedded system called black big bone.
In the end, I just want to be able (compatible) to talk rs232 with reliable timeouts, cancel () reset (), etc., so that it doesn't crash / hang when, for example, the tx or rx line is accidentally disconnected. So I could just copy / paste / accept the existing examples. But I would also like to become more enlightened; -)
I decided to use boost: asio :: serial_port . Now, reading the docs, I'm confused by these two classes (well, three with typedef serial_port):
serial_port_service - The default service implementation for the 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 I see that I need boost::asio::io_service
to build either boost::asio::serial_port
or serial_port_service
. I think I understand the basic approach of how asio does the job like these examples .
OK serial_port_service
comes from io_service, its ctor accepts io_service
, and its interface also offers those member members basic_serial_port
.
For me it looks like an io_service which also implements basic_serial_port - what is the reason for having both classes? When to use the one when the other? Not sure about the possibilities, and what about this serial_port
typedef. Maybe (well, obviously) I'm missing something - can someone give me more light?
source to share
Often an application must use an I / O object. In this case it will be boost::asio::serial_port
.
Various classes are used to separate responsibilities and abstractions. The similarity in the names can be confusing, so the documentation is very careful about naming it. The documentation states:
The class
io_service
implements an extensible, type-safe, polymorphic set of I / O services, indexed by the service type. A class objectio_service
must be initialized before I / O objects such as sockets, resolvers, and timers can be used. These I / O objects differ in constructors that take a parameterio_service&
.There are I / O services to manage the logical interface of the operating system on behalf of I / O objects. In particular, there are resources that are shared across the I / O object class. For example, timers can be implemented in terms of a single timer queue. I / O services manage these shared resources.
To explain this in the context of serial ports:
-
io_service
provides an event loop and manages I / O services such asserial_port_service
. -
serial_port
is an I / O object that provides an interface for performing serial port-related operations. The implementation is very simple:- Defines how information should be returned to the caller: throw, if an error occurs, fill
std::future
, suspend the coroutine , etc. - Cancels valid work with
serial_port_service
its I / O service. - Provides RAII semantics. When
serial_port
destroyed, it will cancel the outstanding asynchronous operations and closeserial_port
.
- Defines how information should be returned to the caller: throw, if an error occurs, fill
-
serial_port_service
is the I / O service:- It provides an abstraction and implements a platform-specific API.
- It is used in conjunction with
serial_port
that uses the sameio_service
. Whenserial_port
created withio_service
,serial_port
will use an existingserial_port_service
one registered withio_service
, or create and register a new oneserial_port_service
withio_service
. - It functions like a factory for an I / O object
implementation
. Forserial_port
this, most likely the underlying file descriptor or descriptor.
source to share