Re: How to write a proper fork hook code?

[Svante Signell]

On Mon, 2015-03-02 at 11:13 +0100, Samuel Thibault wrote:
> 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, as we now have found out.
> 
> It does work, try the attached testcase which uses pthread_atfork which
> works from the atfork hooks.

Yes, my code with fd1 = open() works too, the hook is triggered. The
problematic code is with fd2 = file_name_lookup(9 which obviously don't
created a file descriptor, not enabling the hook code, which iterates
over file descriptors.

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

Parent has a write lock; Others have a write lock.
Child has a write lock; Others have a write lock.

> > 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).

(no hooks involved here)

./test_fork_rpc foo
Parent pid = 4620
Lock type lock.l_type = 'write'
Child PID in the parent = 4621
Parent has a 'write' lock; Others have a 'write' lock.
Child PID in the child = 0
Child has a 'write' lock; Others have a 'unlocked' lock.

The unlock is currently made by initializing the box:
fshelp_rlock_init (box)