[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/6] libfshelp_rlock

From: Svante Signell
Subject: Re: [PATCH 1/6] libfshelp_rlock
Date: Thu, 15 Dec 2016 12:31:55 +0100

On Thu, 2015-03-05 at 02:34 +0100, Samuel Thibault wrote:
> Olaf was wondering about flock being reimplemented over this new
> implementation.  It's actually a tricky question.  I believe there are
> two issues:
> All in all, I'd suggest the following:
> - let's make GETLK however return ENOSYS: we can't fill the l_pid, and
>   this is not worse than what we have ATM.

Is it OK to add to fcntl.diff?
-       return __flock (fd, cmd);
+       err = HURD_FD_PORT_USE (d,
__file_record_lock (port, cmd, fl));
+       if (fl->l_pid == -1)
+       {
  errno = ENOSYS;
+         err = -1;
+       } 
+       result = err ?
__hurd_dfail (fd, err) : 0;
(and in one other place)

> - let's already put the process token in the new RPC API.  Setting it to
>   non-NULL from the client will mean "I want a per-process lock", and
>   for now let's return ENOSYS in that case.

Which RPC and which token name are you thinking of here?

> - later, we'll implement proper per-process locks, by using the token as an
>   identifier of the process.

Which token?

> - we'll then be able to implement GETLK, and in case a per-open lock was
>   taken, we'll put -1 in l_pid, like BSD does.

Please explain!

> - when per-opened file record locks get standardized, we can trivially
>   implement it.

See above.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]