Re: How to write a proper fork hook code?

[Samuel Thibault]

Svante Signell, le Mon 02 Mar 2015 10:17:52 +0100, a écrit :
> On Mon, 2015-03-02 at 10:09 +0100, Samuel Thibault wrote:
> > Svante Signell, le Mon 02 Mar 2015 08:29:55 +0100, a écrit :
> > > Well the basic problem is of course to detect processes generated by
> 
> >  There's no hidden
> > process in there, and the fork hook should get you done.
> 
> I never talked about any hidden process, did I?

Then why would you need to detect them?  You have the parent and child
hooks, they are working.

> > But again, I'm still unsure why you believe that locks are being
> > inherited through fork(): before introducing a fork hook to forcibly
> > unlock something, one needs to be absolutely sure that it's actually
> > locked.  Actually it'd even look like a design flaw if two process could
> > actually hold a lock on the same piece of a file...
> 
> Well, the patches are already submitted, and there is test code for
> locks inherited by fork(2): fork.c

You mean test_fork.c?  As I've mentioned earlier:

«
I believe there is a misunderstanding here: F_GETLK does not
return whether the caller has a lock on the file, but whether there is
an existing lock that would prevent from acquiring one.
»

So I don't believe it is actually testing for inherited locks.

> Maybe you should apply the patches
> and see for yourself, instead of always doubt everything I report :(

Well, you have to understand that review precisely *is* about doubting.
Writing correct code is about doubting as much as possible to avoid
bugs.  If I'm not convinced that the program works one way or another,
I can't apply the patch.  Either I get convinced by reading the source
code and run tests, which would take time for me, and is thus unlikely
to happen soon; or you explain why you think it is working one way
or another.  What I have seen so far doesn't convince me one way or
another.  I'm sorry, but that's how opensource works, you can't just
push code without explanations.

Samuel