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().
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?
Wolfgang.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
