Jan Kiszka wrote: > Jan Kiszka wrote: >> Hi, >> >> I stumbled over a strange behaviour of rt_task_delete for a created, set >> periodic, but non-started task. The process gets killed on invocation, > > More precisely: > > (gdb) cont > Program received signal SIG32, Real-time event 32. > > Weird. No kernel oops BTW. > >> but only if rt_task_set_periodic was called with a non-zero start time. >> Here is the demo code: >> >> #include >> #include >> #include >> >> main() >> { >> RT_TASK task; >> >> mlockall(MCL_CURRENT|MCL_FUTURE); >> >> printf("rt_task_create=%d\n", >> rt_task_create(&task, "task", 8192*4, 10, 0)); >> >> printf("rt_task_set_periodic=%d\n", >> rt_task_set_periodic(&task, rt_timer_read()+1, 100000)); >> >> printf("rt_task_delete=%d\n", >> rt_task_delete(&task)); >> } >> >> Once you skip rt_task_set_periodic or call it like this >> rt_task_set_periodic(&task, TM_NOW, 100000), everything is fine. Tested >> over trunk, but I guess over versions should suffer as well. >> >> I noticed that the difference seems to be related to the >> xnpod_suspend_thread in xnpod_set_thread_periodic. That suspend is not >> called on idate == XN_INFINITE. What is it for then, specifically if you >> would call xnpod_suspend_thread(thread, xnpod_get_time()+period, period) >> which should have the same effect like xnpod_suspend_thread(thread, 0, >> period)? That difference is clear to me now: set_periodic with a start date != XN_INFINITE means "suspend the task immediately until the provided release date" (RTFM...) while date == XN_INFINITE means "keep the task running and schedule the first release on now+period". The actual problem seems to be related to sending SIGKILL on rt_task_delete to the dying thread. This happens only in the failing case. When xnpod_suspend_thread was not called, the thread seems to self-terminate first so that rt_task_delete becomes a nop (no more task registered at that point). I think we had this issue before. Was it solved? [/me querying the archive now...] Jan