From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <47CE8A96.4050609@domain.hid> Date: Wed, 05 Mar 2008 12:57:10 +0100 From: Anders Blomdell MIME-Version: 1.0 References: <47CE7FD5.7080602@domain.hid> <47CE8483.8030600@domain.hid> In-Reply-To: <47CE8483.8030600@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] rt_task_delete of an active task kills main program List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai-help Philippe Gerum wrote: > Anders Blomdell wrote: >> With the following program: >> >> #include >> #include >> #include >> #include >> #include >> #include >> >> >> >> static void child(void *arg) >> { >> int n = (int)arg; >> >> printf("start %d, ", n); fflush(stdout); >> rt_task_sleep(100000000L); >> printf("exit %d, ", n); fflush(stdout); >> } >> >> int main(int argc, char *argv[]) >> { >> int i; >> RT_TASK task_main; >> RT_TASK task; >> >> mlockall(MCL_CURRENT|MCL_FUTURE); >> rt_task_shadow(&task_main, NULL, 1, T_FPU); >> >> for (i = 20 ; i > 0 ; i--) { >> if (rt_task_create(&task, NULL, 0, 1, 0)) { >> fprintf(stderr, "Failed to create task\n"); >> exit(1); >> } >> if (rt_task_start(&task, &child, (void*)i)) { >> fprintf(stderr, "Failed to start task\n"); >> exit(1); >> } >> rt_task_sleep(1000000 + 10000000L * i); >> printf("delete %d\n", i); >> rt_task_delete(&task); >> } >> exit(0); >> } >> >> I get this output: >> >> start 20, exit 20, delete 20 >> start 19, exit 19, delete 19 >> start 18, exit 18, delete 18 >> start 17, exit 17, delete 17 >> start 16, exit 16, delete 16 >> start 15, exit 15, delete 15 >> start 14, exit 14, delete 14 >> start 13, exit 13, delete 13 >> start 12, exit 12, delete 12 >> start 11, exit 11, delete 11 >> start 10, exit 10, delete 10 >> start 9, delete 9 >> Killed >> >> i.e. rt_task_delete of a [still] running task kills the main program. Is this >> the expected behaviour? > > Yes and no. POSIX behaviour kills us sometimes. > > Versions are still: > > Does this patch fix the issue? > > --- ksrc/nucleus/pod.c (revision 3525) > +++ ksrc/nucleus/pod.c (working copy) > @@ -1140,9 +1140,11 @@ > * 2) Make sure shadow threads are removed from the system on > * behalf of their own context, by sending them a lethal > * signal when it is not the case instead of wiping out their > - * TCB. In such a case, the deletion is asynchronous, and > - * killed thread will later enter xnpod_delete_thread() from > - * the exit notification handler (I-pipe). > + * TCB. We only do that whenever the caller is a kernel-based > + * Xenomai context. In such a case, the deletion is > + * asynchronous, and killed thread will later enter > + * xnpod_delete_thread() from the exit notification handler > + * (I-pipe). > * > * Sidenote: xnpod_delete_thread() might be called for > * cleaning up a just created shadow task which has not been > @@ -1166,7 +1168,14 @@ > if (xnthread_user_task(thread) != NULL && > !xnthread_test_state(thread, XNDORMANT) && > !xnpod_current_p(thread)) { > - xnshadow_send_sig(thread, SIGKILL, 1); > + 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 */ > Yep, now I get the expected results: start 19, exit 19, delete 19 start 18, exit 18, delete 18 ... start 2, delete 2 start 1, delete 1 Great thanks! Anders -- Anders Blomdell Email: anders.blomdell@domain.hid Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden