Andi,
Looks like SIGPROF is calling _group_send_sig_info(), so I think it is
subject to the same problem.
I have built a perfmon example to test the problem, it is relatively easy to
trigger by simply self-monitpring a thread which is using setitimer() and
thus SIGALRM. You just have to increase the timer frequency. At some point,
the SIGPROF signal will be delivered to the wrong
thread.
One thing I did not mention in my message is that one would think that
forcing a specific signal via F_SETSIG could be a workaround if that signal
is synchronous, e.g., SIGFPE. F_SETSIG looks like a Linux extension but it
does not solve the problem. Linux determines the mode of delivery not on the
signal number but on the code path, it seems. If you use F_ASYNC+F_SETOWN,
then this is systematically considered asynchronous regardless of the signal
used.If you come from traps.c,
then the signal is delivered to the correct thread.
All of this does not look unreasonable to me.
I believe sampling, be it timer or PMU-based, may be
a special case here. We want asynchronous + specific
thread (only) when self- sampling.
An alternative may be to choose the pending queue based on the signal type.
Then, we could use F_SETSIG
to override SIGIO with a synchronous signal instead.
But I am not a POSIX signal expert.
On Jul 27, 2009 11:25 PM, "Andi Kleen" <[email protected]> wrote:
I wonder how SIGPROF gets around the same problem, or is it
buggy too?
-Andi
--
[email protected] -- Speaking for myself only.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
