Re: [PATCH] Per-task watchers: Enable inheritance

[Peter Williams <pwil3058@bigpond.net.au>]

Matt Helsley wrote:
> 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?
>
> 	Hmm. We may need to be careful with terminology here. Keep in mind that
> a task is not the same as the userspace concept of a  "process".
>
> 	When a task is executing a module's code it will be safe to traverse
> the task's notifier chain to find state. It will *not* be safe to
> traverse the notifier chain of other tasks -- even if the other task is
> a thread in the same "process".

Yes, the client has to make its own arrangements for protecting this 
type of thing.

The "per process CPU caps" code that I'm working on using task watchers 
has to address these issues and indications (so far) are that they're 
solvable.  I should be in a position to post that code early next week 
and, hopefully, that will give some insight into what can be achieved 
with this type of mechanism.  What I've done might not be the best way 
to solve the issues involved but it should provide a starting point for 
discussion :-)

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

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/