Re: How to write a proper fork hook code?
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
Reply to: