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
