All of lore.kernel.org
 help / color / mirror / Atom feed
From: jtk@us.ibm.com (John T. Kohl)
To: "" <matthltc@us.ibm.com>
Cc: "Andrew Morton" <akpm@osdl.org>,
	"Peter Williams" <pwil3058@bigpond.net.au>,
	"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: 26 Jun 2006 09:03:23 -0400	[thread overview]
Message-ID: <6clkrk3w84.fsf@sumu.lexma.ibm.com> (raw)
In-Reply-To: <1151105584.21787.1571.camel@stark>

>>>>> "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).  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.

-- 
John Kohl
Senior Software Engineer - Rational Software - IBM Software Group
Lexington, Massachusetts, USA
jtk@us.ibm.com
<http://www.ibm.com/software/rational/>

  parent reply	other threads:[~2006-06-26 13:03 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 [this message]
2006-06-26 13:27       ` Peter Williams

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=6clkrk3w84.fsf@sumu.lexma.ibm.com \
    --to=jtk@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=balbir@in.ibm.com \
    --cc=jes@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=matthltc@us.ibm.com \
    --cc=nagar@watson.ibm.com \
    --cc=pwil3058@bigpond.net.au \
    --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 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.