On Tue, Jul 28, 2009 at 7:13 AM, stephane eranian<eran...@googlemail.com> wrote: > Andi, > > Looks like SIGPROF is calling _group_send_sig_info(), so I think it is > subject to the same problem. > I did not look into SIGPROF a bit more.
First, SIGPROF is generated from ITIMER_PROF. My understanding is that this is a global timer for the process. It may therefore fire in any thread. Then SIGPROF is pended to the shared signal queue as per the group_send_sig_info() code path. That means the thread receiving the signal may not be the one in which the timer expired. But typically things even out. But things change if the monitored process is using signal, and in particular signals pended to the private signal queue which is what happens with pthread_kill() I would think. Then, yes there may be an imbalance. But in the case of SIGPROF, it is not clear to me if you want to change this behavior as well. It all depends on the definition for ITIMER_PROF. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
