Re: [Xenomai-help] pthread cancelation and scheduling magics

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Wolfgang Grandegger wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Grandegger wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Wolfgang Grandegger wrote:
>>>>> Gilles Chanteperdrix wrote:
>>>>>> Wolfgang Grandegger wrote:
>>>>>>> Gilles Chanteperdrix wrote:
>>>>> [...deletions...]
>>>>>>>> That is not expected. But this brings me back to my initial question, do
>>>>>>>> you have to work with a real world application that runs without issuing
>>>>>>>> any syscall ?
>>>>>>> If a add long nanosleeps, e.g. 100, 10 or 1 ms, cancellation works but
>>>>>>> it fails with short nanosleeps. A syscall seems not sufficient. I have
>>>>>>> the impression that pthread_cancel needs some time in secondary mode to
>>>>>> When calling nanosleep, the threads spends on time in secondary mode. I
>>>>> What do you mean? nanosleep switches to secondary mode?
>>>> I meant spends "no" time in secondary mode. nanosleep does not switch to
>>>> secondary mode.
>>>>
>>>>>> think the problem is rather that only asynchronous cancelation (meaning
>>>>>> cancelation with a signal) works. Setting the cancelation bit somehow
>>>>>> gets lost.
>>>>>>
>>>>>>> do it's duties, e.g. mark the thread as canceled. Would it make sense to
>>>>>>> wrap pthread_cancel, and friends to the corresponding kernel functions
>>>>>>> in ksrc/skins/posix?
>>>>>>> Is there a way to force a thread switching to secondary mode?
>>>>>> No, there is no way to force a thread to switch to secondary mode, the
>>>>>> xnshadow_relax call explicitely requires to be called by the target
>>>>>> thread. Before I wrap pthread_cancel, I would really like to understand
>>>>>> why setting a bit with pthread_cancel and testing it with
>>>>>> pthread_testcancel does not work.
>>>>>>
>>>>>> What is the trace of your test when run:
>>>>>> - on ARM
>>>>>> - with root thread priority inheritance,
>>>>>> - with USE_EXPLICIT_SCHED and USE_TEST_CANCEL, and CANCEL_TYPE set to
>>>>>> PTHREAD_CANCEL_DEFERRED
>>>>>> - posting a semaphore in ctrl_func before calling nanosleep, and waiting
>>>>>> for that semaphore in main before creating the calc_func thread.
>>>>> The calc_thread is not canceled and a segmentation fault happens.
>>>>> Canceling the calc_thread does *not* work if it's running in primrary
>>>>> mode, nor on ARM, nor on PowerPC. It does work when calc_thread does run
>>>>> in secondary mode, which happened with USE_EXPLICIT_SCHED not set. If
>>>>> you want do to some tests, I could send you my revised test program.
>>>>> My conclusion is that pthread_cancel can not be used to cancel busy
>>>>> realtime threads. I'm going to re-write the program using the native
>>>>> skin and rt_task_delete.
>>>> Yes, but what interests me is how it fails, that is seeing the trace of
>>>> your program.
>>> With pthread_cancel you do not see too much because the rt_printf
>>> messages do not get printed:
>> As a temporary quirk, could you try, in rtdk, to install a handler for
>> SIGSEGV which flushes the print buffers ?
> 
> OK. Hm, flushing the rt_print buffers before exit is what I'm actually
> looking for. Registering an cleanup handler would already be enough. But
>   an active real-time task will also delay the exit().

In case of segmentation fault, the SIGSEGV signal is sent to the
application and exit is not called at all, which is why the buffers do
not get flushed, and why I am suggesting to flush them in the SIGSEGV
handler.

> 
> Nevertheless, I tried with the native skin and it cancellation works
> fine with:
> 
> 		rt_task_suspend(&calc_thread);
> 		rt_task_delete(&calc_thread);
> 
> Can I do a task suspend with the Xenomai POSIX skin?

You should not need to suspend the task with the native skin either.
With the posix skin, you still have the same problem: send the SIGSTOP
signal to the task, but it will not work if the task does not issue any
syscall.

-- 
                                                 Gilles.