Provide a means to wait until a file lock can be acquired

[nex3]

The existing file locking functions only provide the means to check whether a lock is available at a given point in time. Applications frequently want to acquire a lock immediately upon it becoming available, and I believe the OS APIs provide the means to do so. Please expose this in the API.

[nex3]

Marked this as blocking #21476.

[sgjesse]

This is an option in the APIs on all platforms. So the sync version can block until the lock becomes available and the async version complete when the locks becomes available.

This could be exposed in the API either through new methods

  lockWait
  lockWaitSync

or by adding an additional argument to lock/lockSync. Adding an additional argument might tip the balance towards optional named arguments.

---

Added this to the 1.9 milestone.
Removed Priority-Unassigned label.
Added Priority-Medium, Accepted labels.

[DartBot]

This comment was originally written by @seaneagan

---

You probably wouldn't want to wait indefinitely, what about a timeout argument:

lock(FileLock mode, {Duration timeout = Duration.ZERO, ...});
lockSync(FileLock mode, {Duration timeout = Duration.ZERO, ...});

By default the timeout is zero, matching the current behavior. There is no way to wait indefinitely, which might be a good thing?

[sgjesse]

The problem with providing a timeout is that the OS APIs does not have a timeout option, and no explicit way of canceling the call.

On Linux and Mac OS sending a signal will make the call return EINTR, and that can be used to cancel the call.

On Windows that is not possible. On Windows it might be possible to schedule LockFileEx as an asynchronous operation completing through a completion port, and then cancel the request using CancelIo if it does not complete before the timeout. However currently we only use completion ports for socket IO, so that might require a larger change.

You can use the timeout method on a Future (https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart:async.Future#id_timeout) to get a Future that completes after a timeout if the original Future does not complete. However the original Future might still complete at some later point.

[kevmoo]

Set owner to @sgjesse.

[sgjesse]

Punting this, to 1.10. We need to have a general way of canceling I/O operations to do this in a consistent way.

Polling can be used as a workaround.

---

Removed this from the 1.9 milestone.
Added this to the 1.10 milestone.

[kasperl]

I assume this isn't a high priority issue (not marked as such) so I'm removing the explicit milestone label.

---

Removed this from the 1.10 milestone.

[zanderso]

678cb04 adds a blocking option to lock and lockSync. Adding a timeout would entail a deeper refactoring, so let's skip it for now. Closing this issue as the originally requested feature has been added.