Thymio Flasher needs to close other Aseba programs before loading

[sharon13m]

If Aseba Studio is open while you open Thymio Flasher.. it severely (and maybe permanently) damages the robot. Thymio Flasher needs to run a check to see if Aseba Studio (and possibly other programs) are open and communicating with the robot, and then shut them down or tell that user that it cannot proceed if the other software is open.

[stephanemagnenat]

I am somewhat puzzled that this happens, as this problem implies that the serial port device can be opened twice. We have to do further tests to see whether this happens on Windows and OS X as well. This problems should be solved in Dashel, by not allowing serial ports to be opened twice.

[retornaz]

fcntl(fd, F_SETLK,...)

[stephanemagnenat]

Interesting, but this function provides "advisory" locks, they are not enforced. A quick search on the net seems to indicate that the only way is through lock files, but then we have to handle dandling lock files in case of crash. We could implement some semi-intelligent check on the lock file to verify that the locking program still runs, but although doable, that's non trivial.

[retornaz]

hem at least if implemented through dashel, it would avoid the asebastudio/thymioflasher mixup. Or we could put back thymioflasher into an asebastudio plugin ......

[stephanemagnenat]

I'm for implementing something in Dashel, for serial ports. First we need to see on which platform this problem happens. Is it only posix? Only OS X?

[retornaz]

Posix

[stephanemagnenat]

Ok, so we go for lock files. This raises some questions:

• Which names do we use for lock files?
• Should the serial enumeration be aware of locks (i.e. ignore locked ports)?
• How do handle devices with symbolic links and udev rules?

I think that flock(2) can work. It exists both on Linux and OS X, and by using the LOCK_NB flag directly after opening the file descriptor, we can check whether there is already a lock, and if, so, return an error in Dashel. One question is then what happens if a Dashel-enabled application crashes and does not release the lock?

[retornaz]

You are mixing two completely unrelated "locking" mechanism.

• Flock/fcntl based one which are bound to an file descriptor, with an automatic release as soon as the FD is closed.
• File based lock which is juste a file in /var/... with a pid written in it. Which need manual handling if the application crash (thus the pid value inside ...)

I think the first one is sufficient as we just want to avoid asebastudio/thymioflasher mixing.

[stephanemagnenat]

I was indeed mixing the two, but note that the first one is linked to a file through its descriptor, so I was afraid it would not be released upon crash.

[retornaz]

huh, why not ?

[retornaz]

manpage of fcntl (we should avoid using flock): "As well as being removed by an explicit F_UNLCK, record locks are automatically released when the process terminates or if it closes any file descriptor referring to a file on which locks are held."

[stephanemagnenat]

why not using flock, the call is simpler and does not include arguments about position which are meaningless for a serial stream?

[retornaz]

ok, go for flock()

[stephanemagnenat]

Fixed in aseba-community/dashel@d13bbbd1df4802101e13e93fb6229d1f7f164e85, we have to see how we propagate this to Aseba.