Boost logo

Boost Users :

Subject: Re: [Boost-users] Boost ASIO 1.66 serial port open seem to never fail opening (at least the way i'm using it)
From: Mathieu Peyréga (mathieu.peyrega_at_[hidden])
Date: 2018-01-12 09:54:11

> Could you please check the previous release of Boost?
> For example, in my case, version 1.65.1 used on CentOS Linux release
> 7.4.1708 (Core).
> If ttyS0 opened with screen (screen /dev/ttyS0 115200) ASIO will not
> open it with error
> $ sreqrep /dev/ttyS0 "%%"
> [2018-01-11 17:49:30.868] [serial] [error] Error: Device or resource busy
> $
> If your case related only to 1.66, then it'll be possible regression bug.
Thanks for the people who answered !
Unfortunatly, i'm not able to try another bosot version right now. I can
not easily change boost version and have not another machine to test.
As suggested I tested starting my software and taking control of
/dev/ttyS0 and then launching screen and screen start correctly (screen
steals the control of /dev/ttyS0 to my software)
If I try to reconnect to /dev/ttyS0 while screen still running, this
time asio gives a no go (I guess screen is putting a "kernel" lock on
the file)
At this point, I guess this is more a Linux point that is really
considering /dev/ttyS0 as a regular file and allows multiple opens
unless the openning process takes a lock on it.
I added that on my serial port wrapper class through flock calls call
from #include <sys/file.h>

flock(this->m_SerialPort.native_handle(), LOCK_EX | LOCK_NB)
flock(this->m_SerialPort.native_handle(), LOCK_UN | LOCK_NB)

at adequate points. This at least prevent other software from tampering
with the serial port i just openned...

> You could use /dev/cua*-devices for this instead of /dev/ttyS*.
> /dev/cua*-Devicess take exclusive use of the serial port, while
> /dev/ttyS* are intended for being used in interactive sessions (with a
> serial terminal attached). Until recently, the linux kernel included a
> file Documentation/devices.txt (It was there in Linux-4.9.72) saying
> /dev/cua* are major 5, minor 64 and up. Newer kernels describe the
> cua*-devices in Documentation/admin-guide/devices.rst.

those files are not exposed on my machine (kernal too old)

mathieu_at_UbuntuMate-VirtualBox:/dev$ uname -a
Linux UbuntuMate-VirtualBox 4.4.0-67-generic #88-Ubuntu SMP Wed Mar 8
16:34:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

About minicom, it's probably getting its own internal mecanism to
prevent several instances openning same port, but not actually taking a
filesystem lock on the /dev/ttyS0 (maybe with a specific option it can
do that but the basic -D device option does not).
This means I should probably also try to see if another process is using
the file. Linux had a fuser or lsof commands for that (and therefore
could be implemented at code level) but they only reports process of the
current user (which would already be better than nothing)

Reading here
it seems that the last option would be to moutn the filesystem a special
way and add special flag to some files but that would be very platform

 From these findings, I believe boost::asio::serial_port should propose
a (default enabled) option to implement "locking" the port at open time
and checking if it's used (at least by same user) pre-open time at
library level, that would make those serial port safer as most of the
time, datastream going though serial ports are really not intended to
have multiple talkers on any side.



tel : +33 (0)6 87 30 83 59

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at