* [Xenomai-help] rt_task_delete behavior
@ 2006-05-18 5:15 Brian L.
2006-05-18 8:00 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Brian L. @ 2006-05-18 5:15 UTC (permalink / raw)
To: xenomai
I'm calling what amounts to rt_task_delete(rt_task_self()) and the
task simply hangs, with this call never returning.
rt_task_delete(NULL) behaves identically.
What could cause this behavior? The problem is embedded within a
nontrivial application, but it seems that it's not behaving according
to spec which says that the caller will only block when:
1. The target is in a "safe section"
and
2. The caller is not the target
Any ideas?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete behavior
2006-05-18 5:15 [Xenomai-help] rt_task_delete behavior Brian L.
@ 2006-05-18 8:00 ` Philippe Gerum
2006-05-19 14:02 ` Brian L.
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2006-05-18 8:00 UTC (permalink / raw)
To: Brian L.; +Cc: xenomai
Brian L. wrote:
> I'm calling what amounts to rt_task_delete(rt_task_self()) and the
> task simply hangs, with this call never returning.
> rt_task_delete(NULL) behaves identically.
>
> What could cause this behavior? The problem is embedded within a
> nontrivial application, but it seems that it's not behaving according
> to spec which says that the caller will only block when:
>
> 1. The target is in a "safe section"
>
> and
>
> 2. The caller is not the target
>
> Any ideas?
>
Could you post the output of
$ cat /proc/xenomai/sched
TIA,
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete behavior
2006-05-18 8:00 ` Philippe Gerum
@ 2006-05-19 14:02 ` Brian L.
2006-05-19 14:46 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Brian L. @ 2006-05-19 14:02 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
CPU PID PRI TIMEOUT STAT NAME
0 0 0 0 R ROOT
On 5/18/06, Philippe Gerum <rpm@xenomai.org> wrote:
> Brian L. wrote:
> > I'm calling what amounts to rt_task_delete(rt_task_self()) and the
> > task simply hangs, with this call never returning.
> > rt_task_delete(NULL) behaves identically.
> >
> > What could cause this behavior? The problem is embedded within a
> > nontrivial application, but it seems that it's not behaving according
> > to spec which says that the caller will only block when:
> >
> > 1. The target is in a "safe section"
> >
> > and
> >
> > 2. The caller is not the target
> >
> > Any ideas?
> >
>
> Could you post the output of
>
> $ cat /proc/xenomai/sched
>
> TIA,
>
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> >
>
>
> --
>
> Philippe.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete behavior
2006-05-19 14:02 ` Brian L.
@ 2006-05-19 14:46 ` Philippe Gerum
2006-05-21 5:03 ` Brian L.
0 siblings, 1 reply; 6+ messages in thread
From: Philippe Gerum @ 2006-05-19 14:46 UTC (permalink / raw)
To: Brian L.; +Cc: xenomai
Brian L. wrote:
> CPU PID PRI TIMEOUT STAT NAME
> 0 0 0 0 R ROOT
>
Is this snapshot obtained while the application is still hanging?
>
> On 5/18/06, Philippe Gerum <rpm@xenomai.org> wrote:
>
>> Brian L. wrote:
>> > I'm calling what amounts to rt_task_delete(rt_task_self()) and the
>> > task simply hangs, with this call never returning.
>> > rt_task_delete(NULL) behaves identically.
>> >
>> > What could cause this behavior? The problem is embedded within a
>> > nontrivial application, but it seems that it's not behaving according
>> > to spec which says that the caller will only block when:
>> >
>> > 1. The target is in a "safe section"
>> >
>> > and
>> >
>> > 2. The caller is not the target
>> >
>> > Any ideas?
>> >
>>
>> Could you post the output of
>>
>> $ cat /proc/xenomai/sched
>>
>> TIA,
>>
>> > _______________________________________________
>> > Xenomai-help mailing list
>> > Xenomai-help@domain.hid
>> > https://mail.gna.org/listinfo/xenomai-help
>> >
>>
>>
>> --
>>
>> Philippe.
>>
>
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete behavior
2006-05-19 14:46 ` Philippe Gerum
@ 2006-05-21 5:03 ` Brian L.
2006-05-21 10:37 ` Philippe Gerum
0 siblings, 1 reply; 6+ messages in thread
From: Brian L. @ 2006-05-21 5:03 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
No...
hold on--self-destruction should never return. The calling task
destroys itself then ceases to continue executing, right?
I suspect that late at night, three days ago, I confused 'not
returning since the calling context is gone' with 'hanging'.
If a thread's function (the one passed to rt_task_start) returns, is
it cleaned up, or is it still neccesary to call rt_task_delete on it?
On 5/19/06, Philippe Gerum <rpm@xenomai.org> wrote:
> Brian L. wrote:
> > CPU PID PRI TIMEOUT STAT NAME
> > 0 0 0 0 R ROOT
> >
>
> Is this snapshot obtained while the application is still hanging?
>
> >
> > On 5/18/06, Philippe Gerum <rpm@xenomai.org> wrote:
> >
> >> Brian L. wrote:
> >> > I'm calling what amounts to rt_task_delete(rt_task_self()) and the
> >> > task simply hangs, with this call never returning.
> >> > rt_task_delete(NULL) behaves identically.
> >> >
> >> > What could cause this behavior? The problem is embedded within a
> >> > nontrivial application, but it seems that it's not behaving according
> >> > to spec which says that the caller will only block when:
> >> >
> >> > 1. The target is in a "safe section"
> >> >
> >> > and
> >> >
> >> > 2. The caller is not the target
> >> >
> >> > Any ideas?
> >> >
> >>
> >> Could you post the output of
> >>
> >> $ cat /proc/xenomai/sched
> >>
> >> TIA,
> >>
> >> > _______________________________________________
> >> > Xenomai-help mailing list
> >> > Xenomai-help@domain.hid
> >> > https://mail.gna.org/listinfo/xenomai-help
> >> >
> >>
> >>
> >> --
> >>
> >> Philippe.
> >>
> >
>
>
> --
>
> Philippe.
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Xenomai-help] rt_task_delete behavior
2006-05-21 5:03 ` Brian L.
@ 2006-05-21 10:37 ` Philippe Gerum
0 siblings, 0 replies; 6+ messages in thread
From: Philippe Gerum @ 2006-05-21 10:37 UTC (permalink / raw)
To: Brian L.; +Cc: xenomai
Brian L. wrote:
> No...
>
> hold on--self-destruction should never return. The calling task
> destroys itself then ceases to continue executing, right?
>
Yes.
> I suspect that late at night, three days ago, I confused 'not
> returning since the calling context is gone' with 'hanging'.
>
> If a thread's function (the one passed to rt_task_start) returns, is
> it cleaned up, or is it still neccesary to call rt_task_delete on it?
>
It's cleanup up automatically. This explains the output of
/proc/xenomai/sched below; the task has indeed gone away, and the only
remaining thread which keeps the process from exiting is likely the main
- non-Xenomai - one which is somehow paused or blocked.
> On 5/19/06, Philippe Gerum <rpm@xenomai.org> wrote:
>
>> Brian L. wrote:
>> > CPU PID PRI TIMEOUT STAT NAME
>> > 0 0 0 0 R ROOT
>> >
>>
>> Is this snapshot obtained while the application is still hanging?
>>
>> >
>> > On 5/18/06, Philippe Gerum <rpm@xenomai.org> wrote:
>> >
>> >> Brian L. wrote:
>> >> > I'm calling what amounts to rt_task_delete(rt_task_self()) and the
>> >> > task simply hangs, with this call never returning.
>> >> > rt_task_delete(NULL) behaves identically.
>> >> >
>> >> > What could cause this behavior? The problem is embedded within a
>> >> > nontrivial application, but it seems that it's not behaving
>> according
>> >> > to spec which says that the caller will only block when:
>> >> >
>> >> > 1. The target is in a "safe section"
>> >> >
>> >> > and
>> >> >
>> >> > 2. The caller is not the target
>> >> >
>> >> > Any ideas?
>> >> >
>> >>
>> >> Could you post the output of
>> >>
>> >> $ cat /proc/xenomai/sched
>> >>
>> >> TIA,
>> >>
>> >> > _______________________________________________
>> >> > Xenomai-help mailing list
>> >> > Xenomai-help@domain.hid
>> >> > https://mail.gna.org/listinfo/xenomai-help
>> >> >
>> >>
>> >>
>> >> --
>> >>
>> >> Philippe.
>> >>
>> >
>>
>>
>> --
>>
>> Philippe.
>>
>
--
Philippe.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-05-21 10:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-18 5:15 [Xenomai-help] rt_task_delete behavior Brian L.
2006-05-18 8:00 ` Philippe Gerum
2006-05-19 14:02 ` Brian L.
2006-05-19 14:46 ` Philippe Gerum
2006-05-21 5:03 ` Brian L.
2006-05-21 10:37 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.