[Xenomai-help] rt_task_delete problem

[Xenomai-help] rt_task_delete problem

[Philipp Keller]

Hello

We have troubles deleting the main task created with rt_task_shadow()
from user space.
In the course of initiating the program, we spawn two other threads from
the main task with rt_task_spawn().
When ending the application, both the spawned tasks can be deleted with
rt_task_delete(), but the main task returns with an unknown error code
when calling rt_task_delete().
We believe to have released all recources before deleting, closing all
sockets and file handlers.
The trouble is that we cannot initiate rt can socket communication again
after failing to delete the main thread.
Doeas anyone have an idea what the probelm may be here?

Thanks for any hint
Philipp

Re: [Xenomai-help] rt_task_delete problem

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1597 bytes --]

Philipp Keller wrote:
> Hello
> 
> We have troubles deleting the main task created with rt_task_shadow()
> from user space.
> In the course of initiating the program, we spawn two other threads from
> the main task with rt_task_spawn().
> When ending the application, both the spawned tasks can be deleted with
> rt_task_delete(), but the main task returns with an unknown error code
> when calling rt_task_delete().

Please post that error. I never tried to delete main, so I would be
interested what happens then.

In any case, deleting the main thread is not required, it will be purged
on process termination. The same happens to your spawned tasks when they
decide to self-terminate.

> We believe to have released all recources before deleting, closing all
> sockets and file handlers.
> The trouble is that we cannot initiate rt can socket communication again
> after failing to delete the main thread.

That must be a different issue. Check /proc/xenomai/rtdm/open_fildes for
any leftover (CAN) file descriptor. Note that rt_dev_close() can fail if
the descriptor is busy. And such thing can happen if you simply kill the
task that currently blocks on a CAN device e.g.

The correct ordering is therefore: close the sockets, catch the failure
in the blocking threads, and make them self-terminate. Granted, note the
most comfortable situation, but I'm sure we can improve it in the future
(e.g. via auto-cleanup also for RTDM file descriptors).

> Doeas anyone have an idea what the probelm may be here?
> 
> Thanks for any hint
> Philipp
> 

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]