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)
