chicken-hackers
[Top][All Lists]
Advanced

[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

Attachment: 0001-Handle-possible-EINTR-in-file-lock-file-lock-blockin.master.patch
Description: Text Data

Attachment: 0001-Handle-possible-EINTR-in-file-lock-file-lock-blockin.chicken-5.patch
Description: Text Data

Attachment: signature.asc
Description: Digital signature


reply via email to

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