Hi, Thanks for your answers, it is getting clearer.
Maybe I am misunderstanding the second waitpid() that waits for the child to exit. I thought of this as something like a rendez-vous where the childs execution is halted temporarily. But I understand now that the attaching process only receives a signal, and the child runs away immediately after it delivers the signal? And that the counters are owned in the context belonging to the attaching process, so it remains available until it closes the file descriptor? Thank you, Andrej On Tue, Nov 25, 2008 at 6:05 PM, stephane eranian <[EMAIL PROTECTED]> wrote: > Hi, > > On Tue, Nov 25, 2008 at 6:35 AM, Andrej van der Zee > <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Probably a very basic question, but unfortunately not for me: When a >> parent process attaches to a forked child it finally can access the >> pfm-context after the parent is finished waiting for the child to >> exit. At this point, is the child task still in kernel memory? And if >> so, at which point does the kernel know it can release it? >> > I think your question is orthogonal to perfmon2. What happens between > a child and its parent is not modified in anyway by perfmon2. > > You need to have the thread stopped when you attach a perfmon2 context. > This is accomplished today via ptrace (PTRACE_ATTACH). Then, you can > detach the thread and let it run to completion. Should you need to read out > some counts before it dies, you'd have to stop the thread again via ptrace. > When the thread eventually terminates, monitoring stops and the context is > automatically detached. Death of a process is a two-step process, there is > a signal (SIGCHLD) and then you need to reclaim the remaining resources > via wait(). > > A key point to understand is that a thread can never reclaim all of > its resources, > this is always accomplished by the thread calling wait(), could be the parent > or the init process. As for the perfmon2 context, it remains available after > the signal and after the wait. The reason for this and this is a key design > choice, is that the "owner" of the perfmon2 context is not the monitored > thread, it is whichever process has a file descriptor open on it. Now you > see why the perfmon2 context can survive the death of the monitored > thread (except for self-monitoring, of course). > > If your question was more along the lines of: can I peek at the child's memory > when I get the SIGCHLD? I think the answer is no because the memory > resource has already been freed by then (do_exit). > -- Andrej van der Zee 2-40-19 Koenji-minami Suginami-ku, Tokyo 166-0003 JAPAN Mobile: +81-(0)80-65251092 Phone/Fax: +81-(0)3-3318-3155 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
