All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai-core <xenomai@xenomai.org>
Subject: Re: [Xenomai-core] [Xenomai-git] Jan Kiszka : native: Rework handling of pthread carrier thread
Date: Sat, 19 Jun 2010 14:28:26 +0200	[thread overview]
Message-ID: <4C1CB7EA.5030005@domain.hid> (raw)
In-Reply-To: <4C1CAF8A.1000900@domain.hid>

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> As for the rt_task_delete/rt_task_join question, I think we should have
>> to call rt_task_join after deleting  a thread, because that is the only
>> way to make sure that all the ressources associated to a thread are free.
> 
> The question is not how we can release resources (that's trivial:
> pthread_detach) but if we officially provide the service "join after
> delete" to the user. If we do this, its limitations and implications on
> the native interface need to be documented. So far this is fuzzy unless
> you know our implementation.

No pthread_detach does not insure you that the ressources are released.
It insures you that they will be released at a later point in time. That
is the point. The only way to ensure that the ressources have been
released, or more precisely, to wait for them to be released, is to call
phtread_join. If you did not want to wait for that, then there was no
point to create the thread joinable in the first place.

Anyway, yes, I agree, this behaviour of rt_task_join should be documented.

> 
> Jan
> 


-- 
					    Gilles.


      reply	other threads:[~2010-06-19 12:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1OKZdD-0003ml-45@domain.hid>
2010-06-04 19:48 ` [Xenomai-core] [Xenomai-git] Jan Kiszka : native: Rework handling of pthread carrier thread Gilles Chanteperdrix
2010-06-04 23:58   ` Jan Kiszka
2010-06-05 12:57     ` Gilles Chanteperdrix
2010-06-05 18:43       ` Jan Kiszka
2010-06-05 18:49         ` Gilles Chanteperdrix
2010-06-05 19:14           ` Jan Kiszka
2010-06-05 19:18             ` Gilles Chanteperdrix
2010-06-05 19:22               ` Jan Kiszka
2010-06-05 19:28                 ` Gilles Chanteperdrix
2010-06-05 20:46                   ` Jan Kiszka
2010-06-06 12:44                     ` Gilles Chanteperdrix
2010-06-18 18:59                       ` Jan Kiszka
2010-06-18 19:06                         ` Gilles Chanteperdrix
2010-06-18 20:17                           ` Jan Kiszka
2010-06-19 10:14                             ` Gilles Chanteperdrix
2010-06-19 11:52                               ` Jan Kiszka
2010-06-19 12:28                                 ` Gilles Chanteperdrix [this message]

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=4C1CB7EA.5030005@domain.hid \
    --to=gilles.chanteperdrix@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.