[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Handle possible EINTR in file-lock, file-l
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH] Handle possible EINTR in file-lock, file-lock/blocking and, file-unlock. |
Date: |
Sat, 4 Mar 2017 17:44:35 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Mon, Feb 06, 2017 at 05:32:20PM +0100, Jörg F. Wittenberger wrote:
> Am 05.02.2017 um 21:07 schrieb Peter Bex:
> > The patch looks good to me. I must say it's not completely clear from
> > the manual what the intended semantics of the nonblocking file-lock
> > procedure are. I guess if another process has the file locked, we
> > simply error out with "cannot lock file"?
>
> This was at least the behavior the code did before.
>
> Actually I'd rather love to see this changed into returning #f instead
> of raising an error.
>
> Reading the documentation, which is not clear at this point, I did
> actually expect (as in "guess") this to be the case.
I wonder what the other hackers think about this.
Attached is a new version of the original patch that applies cleanly
against the newly reorganised version of the posix module. It does
_not_ change the semantics at all.
I'd like to keep the behaviour in master exactly the way it is, but
we could decide to change the semantics to have it return #f in
CHICKEN 5, no need for any compatibility hack like you proposed.
Still, applying the patch to master seems like a good idea because
it's a legitimate bug that's being fixed here.
Cheers,
Peter
0001-Handle-possible-EINTR-in-file-lock-file-lock-blockin.master.patch
Description: Text Data
0001-Handle-possible-EINTR-in-file-lock-file-lock-blockin.chicken-5.patch
Description: Text Data
signature.asc
Description: Digital signature
- Re: [Chicken-hackers] [PATCH] Handle possible EINTR in file-lock, file-lock/blocking and, file-unlock.,
Peter Bex <=