On Wed, 2009-11-04 at 10:20 +0100, Alexandre Coffignal wrote:
> Hello,
>
> I'm trying to use t_delete routine in psos skin (xenomai-2.4.7) from a
> user space application .
> I'm encountring two different behaviors:
> -1- Calling t_delete(0) from a psos task seems to work perfectly (e.g.
> task self deletes).
> -2- Calling t_delete(task_id) with another task id (e.g. current task
> tries to delete another task) doesn't result in task deletion but
> returns 0 (success).
>
> I've been through both psos skin (ksrc/psos+/task.c) and nucleus
> (ksrc/nucleus/pod.c) source code.
>
> xnpod_delete_thread() behaves differently depending on previously
> described t_delete calls:
>
> -1- First case (t_delete(0)):
>
> Execution skip condition in ksrc/nucleus/pod.c at line 1173:
>
> if (xnthread_user_task(thread) != NULL &&
> !xnthread_test_state(thread, XNDORMANT) &&
> !xnpod_current_p(thread)) {
> if (!xnpod_userspace_p())
> xnshadow_send_sig(thread, SIGKILL, 1);
> /*
> * Otherwise, assume the interface library has issued
> * pthread_cancel on the target thread, which should
> * cause the current service to be called for
> * self-deletion of that thread.
> */
> goto unlock_and_exit;
> }
> #endif /* CONFIG_XENO_OPT_PERVASIVE */
>
> and continues to run after it. This results in a successful deletion.
>
>
> -2- Second case:
>
> Execution enters one of the first conditions (if
> (xnthread_user_task(thread))...) but skip the second one :
> xnshadow_send_sig(thread, SIGKILL, 1) is not executed;
> goto unlock_and_exit; instruction is then executed.
> ->Our thread is never deleted.
>
> -3-
> Modifing actual source code by commenting goto intruction or moving it
> into second condition (if (!xnpod_userspace_p()) mentioned above)
> results in a working t_delete (task_id).
>
> - I'm not sure of the possible side effects of such a modification?
> - Is it correct to do so?
>
Nope, this would defeat the purpose of testing those conditions, and end
up breaking the nucleus. The implicit logic behind such block is that a
real-time task should always exit on behalf of its own context, so that
its Linux side never survives the removal of the mated Xenomai shadow
TCB. Otherwise, you would get a real-time Xenomai task running without
any Xenomai TCB.
The fix has to happen in userland, and only there, by implementing what
the comment suggests, which is still missing from the psos skin. i.e.
have the t_delete() wrapper issue pthread_cancel() under the hood, in
src/skins/psos/task.c. The native and POSIX APIs illustrate what is
needed in this respect, albeit the way they implement this is not 100%
portable to the psos skin context.
PS: this discussion should rather happen on xenomai-core. Redirecting
now.
>
> As mentioned in the source code comment, it is assumed "the interface
> library has issued pthread_cancel" ...
> I assume it might be missing somewhere?
>
> Please can you help on this topic?
>
> Thanks in advance.
>
> Please find a patch regarding this modification.
>
> diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
> index 9348ce1..ee362df 100644
> --- a/ksrc/nucleus/pod.c
> +++ b/ksrc/nucleus/pod.c
> @@ -1177,14 +1177,16 @@ void xnpod_delete_thread(xnthread_t *thread)
> !xnthread_test_state(thread, XNDORMANT) &&
> !xnpod_current_p(thread)) {
> if (!xnpod_userspace_p())
> + {
> xnshadow_send_sig(thread, SIGKILL, 1);
> + goto unlock_and_exit;
> + }
> /*
> * Otherwise, assume the interface library has issued
> * pthread_cancel on the target thread, which should
> * cause the current service to be called for
> * self-deletion of that thread.
> */
> - goto unlock_and_exit;
> }
> #endif /* CONFIG_XENO_OPT_PERVASIVE */
>
>
>
> Fabrice.
>
>
> --------------------------------
> CénoSYS <http://www.cenosys.com>
> 10, Rue Xavier Bichat
> F-72000 Le MANS
> --------------------------------
>
>
> _______________________________________________
> Xenomai-help mailing list
> xenomai-h...@gna.org
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
