All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philippe Gerum <rpm@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] rt_task_delete() question
Date: Thu, 30 Mar 2006 23:05:26 +0200	[thread overview]
Message-ID: <442C4816.6030509@domain.hid> (raw)
In-Reply-To: <442C42B5.2070506@domain.hid>

Jan Kiszka wrote:
> Sean McGranaghan wrote:
> 
>>Hello all,
>>
>>I am posting this for a co-worker who is having problems with killing a 
>>real-time task. (He is joining the email list shortly but for now I will pass 
>>responses on to him.) Here is the scenario:
>>
>>1. A Linux process starts up and detaches from the tty (daemon)
>>2. The daemon creates a xeno message queue
>>2. The daemon spawns a xeno task
>>3. The xeno task on startup binds to the queue rt_queue_bind()
>>4. The xeno task waits on the queue recv with infinite timeout
>>5. The daemon process goes to sleep in a join, waiting for the task to exit
>>6. Some time later another program starts
>>7. The other non-realtime program looks up the xeno task name via rt_task_bind()
>>8. The other non-realtime program attempts to delete the task via rt_task_delete()
>>        Failed Attempt #1 - Non-realtime program calls rt_task_delete() and gets
>>                            a segmentation fault
>>        Failed Attempt #2 - Non-realtime program spawns a realtime task which
>>                            binds to original task and tries rt_task_delete().
>>                            Also gets segmentation fault.
>>
>>The was attempted one a system running the latest Xenomai 2.1 release.
>>
>>What is the preferred method to start/join threads from a non-realtime context?
>>
>>Any help is appreciated.
>>
> 
> 
> rt_task_delete is not supposed to work across processes (Hmm, is this
> detail documented somewhere?).
>

Nope, basically because I totally overlooked the issue... but we should 
make this possible, since rt_task_suspend() is already system-scoped. 
Ok, this one is on my todo list.

> Use a normal Linux signal (e.g. SIGTERM) to terminate the daemon
> process. For a clean termination, you should install a signal handler in
> the daemon process which triggers an organised clean-up (all
> RT-resources except tasks have to be released explicitly).
> 
> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 

Philippe.


  reply	other threads:[~2006-03-30 21:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-30 17:48 [Xenomai-help] rt_task_delete() question Sean McGranaghan
2006-03-30 20:42 ` Jan Kiszka
2006-03-30 21:05   ` Philippe Gerum [this message]
2006-03-31 12:12     ` Sean McGranaghan
2006-03-31 10:22 ` Philippe Gerum
2006-03-31 14:20   ` Philippe Gerum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=442C4816.6030509@domain.hid \
    --to=rpm@xenomai.org \
    --cc=jan.kiszka@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.