linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: "John T. Kohl" <jtk@us.ibm.com>
Cc: matthltc@us.ibm.com, Andrew Morton <akpm@osdl.org>,
	Linux-Kernel <linux-kernel@vger.kernel.org>,
	Jes Sorensen <jes@sgi.com>,
	LSE-Tech <lse-tech@lists.sourceforge.net>,
	sekharan@us.ibm.com, Alan Stern <stern@rowland.harvard.edu>,
	Balbir Singh <balbir@in.ibm.com>,
	Shailabh Nagar <nagar@watson.ibm.com>
Subject: Re: [PATCH] Per-task watchers: Enable inheritance
Date: Mon, 26 Jun 2006 23:27:13 +1000	[thread overview]
Message-ID: <449FE0B1.3020808@bigpond.net.au> (raw)
In-Reply-To: <6clkrk3w84.fsf@sumu.lexma.ibm.com>

John T. Kohl wrote:
>>>>>> "Matt" ==   <matthltc@us.ibm.com> writes:
> 
> Matt> On Fri, 2006-06-23 at 17:17 -0400, John T. Kohl wrote:
>>>>>>>> "MattH" ==   <matthltc@us.ibm.com> writes:
> MattH> This allows per-task watchers to implement inheritance of the
> MattH> same function and/or data in response to the initialization of
> MattH> new tasks. A watcher might implement inheritance using the
> MattH> following notifier_call snippet:
>>> I think this would meet our needs--we (MVFS) need to initialize some new
>>> state in a child process based on our state in the parent process
>>> (essentially, module-private inherited per-process state).  It may still
>>> be a bit clumsy to find the per-process state in other situations,
>>> though.  While a process is executing our module's code, would it be
>>> safe to traverse current's notifier chain to find our state?
> 
> Matt> 	Hmm. We may need to be careful with terminology here. Keep in mind that
> Matt> a task is not the same as the userspace concept of a  "process".
> 
> Right, sorry, I was imprecise in my wording.  What MVFS wants is per-task
> private state and state inheritance on task forks.
> 
> Matt> 	When a task is executing a module's code it will be safe to traverse
> Matt> the task's notifier chain to find state. It will *not* be safe to
> Matt> traverse the notifier chain of other tasks -- even if the other task is
> Matt> a thread in the same "process".
> 
> I'm curious to see Peter's prototype code (mentioned in his reply).

It will be delayed as it's gone down my priority list.

>  I
> worry that to get safe access to the parent task's private state during
> fork, we'll need something like a private hash table for our private
> per-task state.  Ideally we'd like to just be able to find stuff hanging
> off the task structure directly.
> 

No, that shouldn't be necessary.  Just use a container_of() wrapper 
model.  During fork() you're in the parent tasks context so should be 
able to access its state through "current".  Fork() is busily copying 
lots of the parent's state into the child so what you want to do should 
be no different.  If you've been using the wrapper idea, the notifier 
block that's passed into the call back code should give access to your 
data for the parent.

If you like I could give you some code snippets to show what I mean.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

      reply	other threads:[~2006-06-26 13:27 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-21  8:47 [PATCH] Per-task watchers: Enable inheritance Matt Helsley
2006-06-21 10:30 ` Peter Williams
2006-06-21 21:27   ` Matt Helsley
2006-06-23 21:17 ` John T. Kohl
2006-06-23 23:33   ` Matt Helsley
2006-06-24  0:08     ` Peter Williams
2006-06-26 13:03     ` John T. Kohl
2006-06-26 13:27       ` Peter Williams [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=449FE0B1.3020808@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=akpm@osdl.org \
    --cc=balbir@in.ibm.com \
    --cc=jes@sgi.com \
    --cc=jtk@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=matthltc@us.ibm.com \
    --cc=nagar@watson.ibm.com \
    --cc=sekharan@us.ibm.com \
    --cc=stern@rowland.harvard.edu \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).