Philippe Gerum wrote:
> Jan Kiszka wrote:
>> Don't raise SIGXCPU while the process is being debugged. These mode
>> changes are expected, and reporting them doesn't provide any helpful
>> information to the application. Rather, it may raise error storms on the
>> application side.
>>
>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
>> ---
>>
>>  ksrc/nucleus/shadow.c |    3 ++-
>>  1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/ksrc/nucleus/shadow.c b/ksrc/nucleus/shadow.c
>> index bcf3b8b..91cf499 100644
>> --- a/ksrc/nucleus/shadow.c
>> +++ b/ksrc/nucleus/shadow.c
>> @@ -1082,7 +1082,8 @@ void xnshadow_relax(int notify)
>>  
>>      xnstat_counter_inc(&thread->stat.ssw);    /* Account for
>> secondary mode switch. */
>>  
>> -    if (notify && xnthread_test_state(thread, XNTRAPSW))
>> +    if (notify && xnthread_test_state(thread, XNTRAPSW) &&
>> +        !xnthread_test_state(thread, XNDEBUG))
>>          /* Help debugging spurious relaxes. */
>>          send_sig(SIGXCPU, current, 1);
>>
> 
> I would rather identify the source of the switch and clear the notify
> flag appropriately from the relax call site.

Sorry, don't get this: What flag do you want to clear? XNTRAPSW?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to