Re: How to write a proper fork hook code?

[Samuel Thibault]

Svante Signell, le Mon 02 Mar 2015 10:57:04 +0100, a écrit :
> On Mon, 2015-03-02 at 10:38 +0100, Samuel Thibault wrote:
> > 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.
> 
> So you mean that I should call the unlock hook code in the parent?

I never meant that, I just meant what I wrote, nothing more: there is
no magic in fork(): it ends up in two processees.  If you want to do
something in the child, you can use the child hook.

> The child hook code does not work as written, aswe now have found out.

It does work, try the attached testcase which uses pthread_atfork which
works from the atfork hooks.

> > > > 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:
> 
> No, I mean fork.c written by Neal.
> http://lists.gnu.org/archive/html/bug-hurd/2015-01/msg00104.html

Ah.  See: that was probably obvious for somebody who has worked on the
patch, but not for somebody who is just following the mails.

Ok, so it seems this is indeed supposed to be testing that.  So what is
the actual output of the test?  I can't find that in your mails.

> I'll given every explanation you asked for so far. Anything else you
> want to know?

How it happens that locks are inherited, so that we can perhaps rather
fix that in libfshelp instead of using a fork hook.  I'm actually afraid
that the fork hook removes the lock from the parent too, which is not
what we want either.  You could try this hypothesis by adding the unlock
explicitly in the child part of your testcase before testing for the
locks (making the parent sleep a bit before making its output, so the
child has the time to perform the unlock).

Samuel

test.c
Description: Text document