On Thu, Jun 30, 2016 at 09:59:37AM +0200, Max Leske wrote:
On 30 Jun 2016, at 05:09, Ben Coman btc@openInWorld.com wrote:
On Tue, Jun 28, 2016 at 6:04 PM, Max Leske maxleske@gmail.com wrote:
Hi,
Opening the same image twice works fine as long as no writes to the .changes file occur. When both images write to the .changes file however it will be broken for both because the offsets for the changes are wrong. This can lead to lost data and predominantly to invalid method source code, which is a pain with Monticello.
I suggest that we implement a kind of lock mechanism to ensure that only one image (the first one opened) can write to the .changes file.
I???ve opened an issue for Pharo here: https://pharo.fogbugz.com/f/cases/18635/The-changes-file-should-be-bound-to-...
Cheers, Max
I just learnt something quite surprising that is probably important to be aware of... "Locks given by fcntl are not associated with the file-descriptor or open-file table entries. Instead, they are bound to the process itself. For example, a process has multiple open file descriptors for a particular file and gets a read/write lock using any one of these descriptors. Now closing any of these file descriptors will release the lock, the process holds on the file. The descriptor that was used to acquire the lock in the first place might still be open, but the process will loose its lock. So, it does not require an explicit unlock or a close ONLY on the descriptor that was used to acquire the lock in fcntl call. Doing unlock or close on any of the open file descriptors will release the lock owned by the process on the particular file."
https://loonytek.com/2015/01/15/advisory-file-locking-differences-between-po...
cheers -ben
Which would solve the problem of a crashed image not cleaning up its lock. Thanks for sharing Ben.
FYI, file locking for Unix/Linux/OS X is supported in OSProcess, see UnixProcessFileLockTestCase and the 'file locking' tests in UnixProcessAccessorTestCase.
Dave