QSerialPort permissions problem (No. Not the easy problem)
-
@Christian-Ehrlicher This is not an problem with accessing the ports at the same time. But this brings up a question, how is this exclusivity implemented? Is it possible that a lock is left hanging if the a program exits improperly?
-
@dhkaplan said in QSerialPort permissions problem (No. Not the easy problem):
Is it possible that a lock is left hanging if the a program exits improperly?
At least on linux yes - see /tmp/lockTTYS0 (or something similar - don't remember exactly the naming of the file but it's obvious when you see it).
-
@dhkaplan said in QSerialPort permissions problem (No. Not the easy problem):
Is it possible that a lock is left hanging if the a program exits improperly?
At least on linux yes - see /tmp/lockTTYS0 (or something similar - don't remember exactly the naming of the file but it's obvious when you see it).
@Christian-Ehrlicher Ah ha! There they are. Are they left hanging if the devices are not explicitly closed before the program exits?
-
I think they're created as QTemporaryFile so they should only be there when the program crashes - at least I would expect this.
-
I think they're created as QTemporaryFile so they should only be there when the program crashes - at least I would expect this.
@Christian-Ehrlicher Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination. I'd prefer it if this lock feature were optional.
-
@dhkaplan said in QSerialPort permissions problem (No. Not the easy problem):
Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination. I'd prefer it if this lock feature were optional.
And keep in mind that lock files implemented by the QSerialPort are specific to Qt, and NOT Linux system level..IOW, they only protect exclusive access in Qt applications.
-
@dhkaplan said in QSerialPort permissions problem (No. Not the easy problem):
Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination. I'd prefer it if this lock feature were optional.
And keep in mind that lock files implemented by the QSerialPort are specific to Qt, and NOT Linux system level..IOW, they only protect exclusive access in Qt applications.
@Kent-Dorfman That's correct. No issues with non-Qt access to the serial ports.
-
@Christian-Ehrlicher Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination. I'd prefer it if this lock feature were optional.
Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination.
If that's the case, then it would be a bug. Because the design is as follows:
The lock file is removed in QSerialPortPrivate::close(), which is called from QSerialPort::close() which is called from the destructor ~QSerialPort()
Result: the lock file should be removed when the serial port object is removed.
Regards
-
Along the lines of serial port control in Linux, nothing says you HAVE to use the Qt classes for serial access. I usually just do POSIX programming in a separate thread with its own read loop and select() to read data when it's available...because I'm much familiar more with POSIX system programming. It's then not too hard to make the data available to the GUI thread via an IPC mechanism.
The dystopian literature that served as a warning in my youth has become an instruction manual in my elder years.
-
Along the lines of serial port control in Linux, nothing says you HAVE to use the Qt classes for serial access. I usually just do POSIX programming in a separate thread with its own read loop and select() to read data when it's available...because I'm much familiar more with POSIX system programming. It's then not too hard to make the data available to the GUI thread via an IPC mechanism.
I usually just do POSIX programming in a separate thread
Yeah, but that's not cross-platform ;)
-
@aha_1980 said in QSerialPort permissions problem (No. Not the easy problem):
Yeah, but that's not cross-platform ;)
Op said he's working on Linux. Actually, I usually recommend manager daemons for access to I/O devices and use of IPC to communicate with them. By abstracting in that way the benefits are: much easier to unit test and validate, and the ability to trivially swap to different IO mechanisms. If your Serial daemon reships the data as a TCP stream then your clients only need to implement a TCP client handler...and guess what? Your serial data no longer needs to reside on the local machine. Then there is GPIO...NEVER give a userland client program direct access to GPIO. Always run it through a manager so that the client can only fiddle with the channels intended, and in a way that doesn't break things.
Anyway, more than enough comment to spawn a suitable flame war, so I digres.
-
@Christian-Ehrlicher Apparently, the lock file is removed only if the QSeialPort::close() method is called, not if implicitly closed by (proper) program termination. I'd prefer it if this lock feature were optional.
@dhkaplan said in QSerialPort permissions problem (No. Not the easy problem):
I'd prefer it if this lock feature were optional.
Lock files it is a common practicle. Besides, it gives same behavior on different platforms (as on Windows the serial ports opened only with exclusive access). And I can't imagine at all a situation when needs an access to the same serial port from different processes.
-
@aha_1980 said in QSerialPort permissions problem (No. Not the easy problem):
Yeah, but that's not cross-platform ;)
Op said he's working on Linux. Actually, I usually recommend manager daemons for access to I/O devices and use of IPC to communicate with them. By abstracting in that way the benefits are: much easier to unit test and validate, and the ability to trivially swap to different IO mechanisms. If your Serial daemon reships the data as a TCP stream then your clients only need to implement a TCP client handler...and guess what? Your serial data no longer needs to reside on the local machine. Then there is GPIO...NEVER give a userland client program direct access to GPIO. Always run it through a manager so that the client can only fiddle with the channels intended, and in a way that doesn't break things.
Anyway, more than enough comment to spawn a suitable flame war, so I digres.
@Kent-Dorfman
Out of curiosity, and not wanting to start a flame war, I'm slightly surprised that you ship I/O access out-of-process. It may well be convenient for debugging/testing, but for production? Then again I know nothing about hardware, so you may so that serial port top speed is slow it doesn't matter, I don't know....
