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

Brad King brad.king at kitware.com
Mon Oct 13 10:39:08 EDT 2014


On 10/10/2014 07:45 AM, Ruslan Baratov wrote:
>    file(TRY_LOCK "/path/to/file" result) # try to lock and return TRUE on success (needed?)
>    file(LOCK ...) # lock until unlock (unlock by further code (what if exit/crashed?) or by deamon)

The LOCK signature should have a timeout after which it returns failure
instead of blocking forever.  One can just use a timeout of 0 to get
TRY_LOCK behavior without a separate signature for it.  Or, by leaving
out the timeout, one can ask to block forever waiting for the lock.

>    file(LOCK_GUARD ...) # lock for scope of current function or until exit

I think the GUARD part can be an option to file(LOCK).  We may need more
than one to determine the scope, e.g.

  file(LOCK GUARD_FUNCTION ...)
  file(LOCK GUARD_PROCESS ...)

>    file(UNLOCK ...) # explicit unlock of LOCK/LOCK_GUARD

Perhaps

  file(LOCK RELEASE ...) # unlock now
  file(LOCK UNGUARD ...) # drop guard

> 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.

> If any of this commands failed (e.g. have no permissions) - exit with 
> unsuccessful code (i.e. FATAL_ERROR) ?

The commands should all have an optional result argument so callers can
find out what happened.  If it is not provided, then failure can result
in a FATAL_ERROR.

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.

Also, please post a summary of how the implementation will work on each
platform.

Thanks,
-Brad




More information about the cmake-developers mailing list