On 13-Oct-14 18:39, Brad King wrote:
With all the above in mind, please brainstorm and propose a more complete
signature set. You can use the keyword/value pairing common in other
commands to avoid needing a positional argument for every value.
What do you think about this:
file(
LOCK <path>
[DIRECTORY] # if present locked file will be <path>/cmake.lock
(instead of <path>)
[RELEASE] # do explicit unlock
[GUARD <FUNCTION|FILE|PROCESS>] # if not present - set to `GUARD
PROCESS` (not used if RELEASE)
[RESULT_VARIABLE <variable>] # 0 on success, error message
otherwise; if not present - any error is FATAL_ERROR
[TIMEOUT <seconds>]
# 0 - return immediately if operation failed (try_lock),
otherwise timeout (timed_lock);
# if not present - lock until success (or error);
# not used if RELEASE;
)
?
On 13-Oct-14 18:39, Brad King wrote:
Also, please post a summary of how the implementation will work on each
platform.
Boost implementation of file locking mechanism use
LockFileEx/UnlockFileEx for windows and fcntl for unix-like platforms.
These functions lock file only for current process. When process crashes
lock removed by OS automatically.
In terms of boost documentation `file(LOCK ...)` locks are exclusive and
advisory.
boost.interprocess:
http://www.boost.org/doc/libs/1_56_0/doc/html/interprocess/synchronization_mechanisms.html#interprocess.synchronization_mechanisms.file_lock
LockFileEx:
http://msdn.microsoft.com/library/windows/desktop/aa365203%28v=vs.85%29.aspx
UnlockFileEx:
http://msdn.microsoft.com/library/windows/desktop/aa365716%28v=vs.85%29.aspx
fcntl (linux):
http://linux.die.net/man/2/fcntl
fcntl (mac):
https://developer.apple.com/library/Mac/documentation/Darwin/Reference/ManPages/man2/fcntl.2.html
I've tried (Un)LockFileEx/fcntl on windows (including mingw and cygwin),
linux and mac - works fine for me with one exception: cygwin's lock is
not visible by win32's lock. I.e. you can synchronize multiple cygwin
processes and multiple windows "normal" processes, but you can't mix them.
On 13-Oct-14 18:34, Ben Boeckel wrote:
Maybe we need something like the 'trap' shell builtin which runs code on
various triggers rather than something like file/directory locks...
Note that you can't set trap for SIGKILL. So if somebody will terminate
your CMake instance by `kill -9 <pid>` probably you will have a problem.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
