On Tue, Jul 28, 2009 at 7:13 AM, stephane eranian 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 glob
(add Roland)
On 07/29, Peter Zijlstra wrote:
>
> On Mon, 2009-07-27 at 18:51 +0200, stephane eranian wrote:
> >
> > POSIX does not mandate that asynchronous signals be delivered
> > to the thread in which they originated. Any thread in the process
> > may process the signal, assuming it does not h
On 07/30, Peter Zijlstra wrote:
>
> On Thu, 2009-07-30 at 00:17 +0200, Oleg Nesterov wrote:
> > (add Roland)
>
> but you seem to have forgotten to actually edit the CC line, fixed
> that ;-)
Yes, thanks ;)
> > On 07/29, Peter Zijlstra wrote:
> > >
> > > On Mon, 2009-07-27 at 18:51 +0200, stephane
On 07/30, Peter Zijlstra wrote:
>
> I'll make a patch for F_SETOWN_TID then, unless someone
> comes up with a better name for the creature ;-)
I think you are right. It is not safe to change the current
behaviour.
Oleg.
---
On Thu, Jul 30, 2009 at 10:28 PM, Oleg Nesterov wrote:
> On 07/30, Peter Zijlstra wrote:
>>
>> I'll make a patch for F_SETOWN_TID then, unless someone
>> comes up with a better name for the creature ;-)
>
> I think you are right. It is not safe to change the current
> behaviour.
>
I agree. As I sai
On Thu, 2009-07-30 at 21:20 +0200, Oleg Nesterov wrote:
> Yes, this allows to send a private signal to sub-thread.
>
> But this is a bit strange, because the user can't specify it wants
> a thread-specific signal to the main thread, its tid == pid.
Ah, indeed. I'll make a patch for F_SETOWN_TID
On Thu, 2009-07-30 at 00:17 +0200, Oleg Nesterov wrote:
> (add Roland)
but you seem to have forgotten to actually edit the CC line, fixed
that ;-)
> On 07/29, Peter Zijlstra wrote:
> >
> > On Mon, 2009-07-27 at 18:51 +0200, stephane eranian wrote:
> > >
> > > POSIX does not mandate that asynchron
On Wed, 2009-07-29 at 14:37 +0200, stephane eranian wrote:
>
> >
> > Now I was considering teaching send_sigio_to_task() to use
> > specific_send_sig_info() when fown->pid != fown->group_leader->pid or
> > something, but I'm not sure that won't break anything.
> >
> Yes, that's the problem with to
Peter,
On Wed, Jul 29, 2009 at 2:19 PM, Peter Zijlstra wrote:
> On Mon, 2009-07-27 at 18:51 +0200, stephane eranian wrote:
>> I believe there is a problem with the current perf_counters (PCL)
>> code for self-sampling threads. The problem is related to sample
>> notifications via signal.
>>
>> PCL
On Mon, 2009-07-27 at 18:51 +0200, stephane eranian wrote:
> I believe there is a problem with the current perf_counters (PCL)
> code for self-sampling threads. The problem is related to sample
> notifications via signal.
>
> PCL (just like perfmon) is using SIGIO, an asynchronous signal,
> to not
Andi,
On Tue, Jul 28, 2009 at 10:56 AM, Andi Kleen wrote:
> On Tue, Jul 28, 2009 at 10:51:04AM +0200, stephane eranian wrote:
>> [Reposting the message because of stupid MIME-encoding error on my part]
>> Andi,
>>
>> Looks like SIGPROF is calling _group_send_sig_info(), so I
>> think it is subject
On Tue, Jul 28, 2009 at 10:51:04AM +0200, stephane eranian wrote:
> [Reposting the message because of stupid MIME-encoding error on my part]
> Andi,
>
> Looks like SIGPROF is calling _group_send_sig_info(), so I
> think it is subject to the same problem.
So sounds like a whole class of signals ca
[Reposting the message because of stupid MIME-encoding error on my part]
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-monitoring a threa
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
I wonder how SIGPROF gets around the same problem, or is it
buggy too?
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. S
On Mon, 2009-07-27 at 18:51 +0200, stephane eranian wrote:
> Hi,
>
> I believe there is a problem with the current perf_counters (PCL)
> code for self-sampling threads. The problem is related to sample
> notifications via signal.
>
> PCL (just like perfmon) is using SIGIO, an asynchronous signal,
16 matches
Mail list logo