DIYEFI.org Forum

That's right, if you wanna stick "FreeEMS Compatible" or "Works with FreeEMS" on your software, for the sake of all users, it MUST support serial device locking. This is not optional and anything that wants to be official software should have this in place and working on all three platforms by the time 0.2.0 of the firmware is released.

I've personally lost too much time with this, and I know for a fact that others have too.

In general serial locking is a bit of a mess, however there is no reason that we can't synchronise our own applications between us. It doesn't matter if it doesn't work with other apps that use the port, chances of having those running at the same time = slim to none anyway. Chances of forgetting the loader is still connected or that emstudio or mtx or lacerated pempheridae etc are still connected is very high and happens regularly to both users and developers.

It'd be better if we went with something as standard as possible so as to increase the chance of it working with random other apps.

Windows, Mike says it's on by default. Verify this.
Linux, what's the best way to go?
OSX, what's the best way to go?

Hash it out here, folks, this should be a priority for all developers.

Fred.

Is this just managing a file in /run/lock/ to say when the port is in use?

Yeah, pretty much. But in a way that is guaranteed to work inside our project.

From http://en.wikipedia.org/wiki/File_locking
"Although some types of locks can be configured to be mandatory, file locks under Unix are by default advisory. This means that cooperating processes may use locks to coordinate access to a file among themselves, but uncooperative processes are also free to ignore locks and access the file in any way they choose. In other words, file locks lock out other file lockers only, not I/O."

In other words, as long as we all support locking, we can't screw up each other, but other people can still screw us up. I reccomend http://linux.die.net/man/2/flock on Linux.

[21:29] -emstudio-dev:#freeems-dev- [emstudio] malcom2073 pushed 1 new commit to dev: http://git.io/tf8slg
[21:29] -emstudio-dev:#freeems-dev- [emstudio/dev] Addition of advisory lock upon opening serial port in linux - Michael Carpenter

malcom2073 wrote:From http://en.wikipedia.org/wiki/File_locking
"Although some types of locks can be configured to be mandatory, file locks under Unix are by default advisory. This means that cooperating processes may use locks to coordinate access to a file among themselves, but uncooperative processes are also free to ignore locks and access the file in any way they choose. In other words, file locks lock out other file lockers only, not I/O."

In other words, as long as we all support locking, we can't screw up each other, but other people can still screw us up. I reccomend http://linux.die.net/man/2/flock on Linux.

Exactly!

So, I reviewed your code, and it looks good. Unfortunately I don't have a compliant locking app to test against. I note that no files get created in /var/lock, but that I had stale locks laying around in there from an unknown source:

fred@cheetah:/mnt/video/tv/Animaniacs 1-50$ l /var/lock/
total 8
-rw-r--r-- 1 fred fred 10 Aug 30 16:27 LCK..ttyUSB1
-rw-r--r-- 1 fred fred 10 Aug 30 16:24 LCK..ttyUSB2

At first I thought "maybe it was the warner brothers (and the warner sister, Dot!)?, then I found the source:

fred@cheetah:~/workspaces/MegaTunix$ grep -rn LCK\.\. .
./src/locking.c:239: tmpbuf = g_strdup_printf("/var/lock/LCK..");
./msloader/loader_common.c:239: lock = g_strdup_printf("/var/lock/LCK..");

These files contain a PID so I tried to test it by running against itself, which in the past worked, but failed with this:



So I filed an issue on Dave's private, censored tracker: http://megatunix.com/tracker/view.php?id=25

Then I checked for open semantics matching yours

fred@cheetah:~/workspaces/MegaTunix$ grep -rn LOCK_ . | grep -v Binary | grep -v BLOCK | grep -v CLOCK
fred@cheetah:~/workspaces/MegaTunix$

But no such luck. So I filed another issue on Dave's private, censored tracker: http://megatunix.com/tracker/view.php?id=26

I also tried cutecom, though I didn't check the source for LOCK open calls, yet. It didn't play nice with emstudio, either way. Checked, nothing:

fred@cheetah:~/Downloads/cc/cutecom-0.22.0$ grep -rn LOCK .
fred@cheetah:~/Downloads/cc/cutecom-0.22.0$

Thank you for your very quick turn around on that! Let's see if we can get at least two apps to work nicely together in the short term. Perhaps John would like to take a stab?

Fred.

http://refspecs.linuxfoundation.org/FHS ... KLOCKFILES

Issue 26 on secret tracker has been updated.

Dave's taken offense to the private, secret, censored comments. It's not private, that is true... See his #26 for more info.

Now that Dave has cleared out his "only one MTX" feature/bug I've tested his implementation and, superficially, it appears to work. I'm not going to invest time into seeing if parallel creation of the file is properly handled or not, though. There could still be concurrency issues present there.

Dave, if you're reading this, pay special attention to the first post.

Fred.

Dare I mention live data stream viewing with OLV?