From what I can gather looking at kernel docs (install kernel-doc pkg, read /usr/share/doc/linux-doc/filesystems/ locks.txt and mandatory-locking.txt.gz), it appears that locking in general in linux is basically a mess, and its because every other unix seems to have done it differently over the years. I couldn't find any information whether the serial layer in linux blocks multiple access, but a simple check of running megatunix and cutecom seems to indicate there's nothing to stop two processes from opening the same device and trouncing all over each other.
I even tried adding calls to flock() as well as fcntl() in mtx and it still lets the other process take the stream, so I'd say the only solution is either no locking at all (which seems to be the case of most apps), or advisory locking using /var/lock/..., though that requires each app have the implementation done correctly, neither of which are completely ideal. MegaTunix DOES do the /var/lock/.. advistory locking correctly however. if you start one instance and let it find an ecu, and then start another mtx instance, it won't trounce the first, and the comms tab will show on the second instance, another app has /dev/ttyUSB0 open and not try and override it . MegaTunix is checking the contents of the lockfile (which should contain the PID of the process that created it), and seeing if that process is still running, thus its able to recover from a crashed instance that left a stale lockfile..
So, as it stands, to advisory lock, or not, that is the question?. Beware this isn't portable to windows, but windows may prevent multiple apps talking to the same device anyways so it may be moot, I haven't investigated this thoroughly.
To see the ugly code that does this, look at locking.c in the megatunix source or
https://github.com/djandruczyk/MegaTuni ... /locking.c The functions of interest are "lock_serial()" and unlock_serial()", Most of the others are disabled and will eventually be removed.
