All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-core] [RFC][patch] per-process data.
Date: Mon, 08 May 2006 15:05:54 +0200	[thread overview]
Message-ID: <445F4232.70201@domain.hid> (raw)
In-Reply-To: <17502.32006.418774.459215@domain.hid>

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Likely I did not yet get the full picture: What prevents using another
>  > adeos per-task key for this? 
> 
> We would need a per-task key for every skin that needs a per-process
> data,

Not necessarily, we could attach a chain of per-skin data objects to the
key pointer.

> but more importantly, we would need to track the clone syscalls
> (that would be another adeos event) in order to propagate the per-task
> data to each thread of the process. Or maybe ptds are inherited upon
> clone ?

Ok, I see the problem, no hook to save here.

> 
> And why is it required to establish a new
>  > termination hook? Are there scenarios where the existing
>  > task-termination hook is not suited for the planned cleanup work?
> 
> Because the existing hook is called once for every thread exit, whereas
> the pexit event get triggered when the last thread of a process exits,
> this is the only moment we are sure we can destroy per-process data.
> 
> Using the existing hook, we would need to decrement a reference counter
> in the hook, but then we would (again) need to track the clone syscalls
> in order to increment the reference counter.
> 
> Both implementations require to add an adeos event, the one I chose, if
> it works, avoid reference counting.
> 

My motivation for suggesting the keys were avoiding the
hash-table-lookup for mm structs. If we maintain some pointer on a
per-thread basis, we would only have to walk over all skins, not all
colliding elements in a hash chain.

I cannot show any code to compare both approaches w/ complexity and
efficiency. Maybe your approach is actually leaner, but my feeling is
that something based on per-task pointers might have advantages as well.

Moreover, having a clone hook may open further doors: establishing hooks
to clone shadow threads...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

  parent reply	other threads:[~2006-05-08 13:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-07 18:00 [Xenomai-core] [RFC][patch] per-process data Gilles Chanteperdrix
2006-05-07 21:15 ` Jan Kiszka
2006-05-07 23:04   ` Gilles Chanteperdrix
2006-05-08 10:18     ` Dmitry Adamushko
2006-05-08 12:47       ` Gilles Chanteperdrix
2006-05-08 13:05     ` Jan Kiszka [this message]
2006-05-08 12:51 ` Gilles Chanteperdrix
2006-05-08 13:14   ` Gilles Chanteperdrix
2006-05-08 13:51   ` Philippe Gerum
2006-05-09 17:49     ` Gilles Chanteperdrix
2006-05-09 22:09       ` Philippe Gerum
2006-05-10 13:03         ` Gilles Chanteperdrix
2006-05-11 12:53           ` Philippe Gerum
2006-05-11 14:03             ` Gilles Chanteperdrix
2006-05-11 14:12               ` 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=445F4232.70201@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=gilles.chanteperdrix@xenomai.org \
    --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.