nq: revamp waiting loop to avoid busy loops in contested cases

As reported in #37, the current rewind-loop has the issue of waiting
for a lock on the first file that is locked, but it could be detected
as being locked by another process that also just wants to check this
file.  As both processes rewind the dir and retry in this case, this
can yield a busy loop.

Instead, find the newest locked file and wait for that.  This should
result in most nq processes waiting for different locks, so this kind
of synchonization cannot appear.

In theory, removing the rewinddir would be enough, as later nq runs
should not result in enqueuing earlier jobs, but it's better to be
safe and check there are no more locked files before we launch
our job.

0 files changed, 0 insertions, 0 deletions