Jan Kiszka wrote: > Hi, > > Gilles' work on cancellation for the posix skin reminded me of this > issue I once discovered in the native skin: > > https://mail.gna.org/public/xenomai-core/2005-12/msg00014.html > > I found out that this can easily be fixed by switching the pthread of a > native task to PTHREAD_CANCEL_ASYNCHRONOUS. See attached patch. > > > At this chance I discovered that calling rt_task_delete for a task that > was created and started with T_SUSP mode but was not yet resumed, locks > up the system. More precisely: it raises a fatal warning when > XENO_OPT_DEBUG is on. Might be the case that it just works on system > without this switched on. Either this is a real bug, or the warning > needs to be fixed. (Deleting a task after rt_task_suspend works.)
Actually, the fatal warning happens when starting with rt_task_start the task which was created with the T_SUSP bit. The task needs to wake-up in xnshadow_wait_barrier until it gets really suspended in primary mode by the final xnshadow_harden. This situation triggers the fatal, because the thread has the nucleus XNSUSP bit and is running in secondary mode. This is not the only situation where a thread with a nucleus suspension bit need to run shortly in secondary mode: it also occurs when suspending with xnpod_suspend_thread() a thread running in secondary mode; the thread receives the SIGCHLD signal and need to execute shortly with the suspension bit set in order to cause a migration to primary mode. So, the only case when we are sure that a user-space thread can not be scheduled by Linux seems to be when this thread does not have the XNRELAX bit. -- Gilles Chanteperdrix.