Re: [Chicken-hackers] [PATCH] Handle possible EINTR in file-lock, file-lock/blocking and, file-unlock.

[Evan Hanson]

Hi folks,

On 2017-03-04 17:44, Peter Bex wrote:
> On Mon, Feb 06, 2017 at 05:32:20PM +0100, Jörg F. Wittenberger wrote:
> > This was at least the behavior the code did before.
> > 
> > But that would be an incompatible change wrt. the current behavior.
> > Hence I did not mix this with the bugfix.
>
> 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.

Thanks for that. I've applied this to master and chicken-5 as-is. We can
change the behaviour on EINTR in a later commit, if we decide it should
indeed change.

> > 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"?
> >
> > 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.

Hmmmm... I don't have a strong opinion about it. Returning #f would
probably be more convenient. However, I do feel strongly that, should we
decide to return #f, we ought to do so only for EWOULDBLOCK and continue
to signal an exception in all other error cases.

Anyway, pushed. Thanks for the patch, Jörg!

Evan

signature.asc
Description: PGP signature