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

[Peter Williams]

John T. Kohl wrote:
> > > > > > "Matt" ==   <matthltc@xxxxxxxxxx> writes:
>
> Matt> On Fri, 2006-06-23 at 17:17 -0400, John T. Kohl wrote:
> > > > > > > > "MattH" ==   <matthltc@xxxxxxxxxx> 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@xxxxxxxxxxxxxx

"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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/