On Tue, Nov 25, 2008 at 10:33 AM, Andrej van der Zee <[EMAIL PROTECTED]> wrote: > 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? > The second waitpid() near the end is to reclaim the child's resources. And yes, the counters values (perfmon2 state) remains available until the last file descriptor on it closes.
> 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
