[cmake-developers] New command 'file(LOCK_DIRECTORY ...)'

[Matthew Woehlke]

On 2014-12-17 16:58, Ruslan Baratov via cmake-developers wrote:
> On 17-Dec-14 21:11, Matthew Woehlke wrote:
>> On 2014-10-13 10:39, Brad King wrote:
>>> On 10/10/2014 07:45 AM, Ruslan Baratov wrote:
>>>> Locking directory is equivalent to locking file `cmake.lock` in
>>>> directory "/path/to/shared/directory/":
>>> I think this can be activated buy a DIRECTORY option.
>> Why do we need even that? Can't CMake just test if the lock target is a
>> directory?
> I've used boost.interprocess as a hint for implementation, as far as I
> know boost::interprocess::file_lock is not able to lock directories:
>   terminate called after throwing an instance of
> 'boost::interprocess::interprocess_exception'
>     what():  Is a directory
> 
> I'm not saying that it's not possible, just trying to use well-known
> cross-platform solution.

Locking a directory "as such" may not be possible (that wouldn't
surprise me). That's not what I meant, though; what I meant is, rather
than make the user say "this is a directory" to instead lock a special
file name in the directory, just have CMake check if the path is a
directory and then use that logic implicitly. Requiring the user to
specify seems superfluous when it's trivial for CMake to just check.

Example:

  file(LOCK /path/to/file) # lock /path/to/file
  file(LOCK /path/to) # lock /path/to/.cmake_lock

(And before anyone mentions it, I have limited sympathy for someone
locking a non-existing directory and then later trying to create it.
Don't do that :-). I'm having a very hard time coming up with a reason
why one wouldn't just create the directory first to ensure it exists.)

For that matter, do we even *need* this feature? If I want to lock a
"directory", is it worth the extra implementation complexity just to
save me inventing some arbitrary name for a lock file?

>> p.s. For a lock with no timeout, maybe there can be a built-in timeout
>> after which CMake displays a message what it's trying to do, so that it
>> doesn't just hang mysteriously.
>
> You can use `message` command:
> 
>     message(STATUS "Try to lock ${file}")
>     file(LOCK ${file})
> 
> or more complex (more user-friendly):
> 
>   while(TRUE)
>     file(LOCK "${file}" RESULT is_locked TIMEOUT 5)
>     if(is_locked)
>       message("Locked. ${resource_info}")
>       break()
>     endif()
>     string(TIMESTAMP time_now "%S/%M")
>     message("[${time_now}] Lock failed, retry... (file: ${file})")
>   endwhile()

Sure. I was just thinking out loud if folks are worried about CMake
"mysteriously" hanging, this (implemented in CMake proper) would be an
option to allay those concerns. (I'd also encourage anyone writing
locks, especially with no time out, to always say what they're doing
first :-). But that's somewhat a separate issue.)

-- 
Matthew