On Tue, Jan 11, 2005 at 09:11:25AM -0600, Erik Jacobson wrote:
> Just to make sure I understand --
>
> You'd use this in case you want to be notified about each task but you
> don't necessarily want paggs allocated for each task as you have no
> desire to group them. Is that right?
Yes.
>
> If so, I just didn't think of that use. I thought people who wanted the init
> function would also want pagg associations. Could a person who wants
> notification of all processes use something like
> for_each_process/for_each_task instead?
I see. (I'm not sure what you mean by using
for_each_process/for_each_task for all processes though).
I had the impression that the only difference between init and attach
was that init served to catch all existing tasks and attach all tasks
during a fork.
As for skipping pagg associations, my thought was that there might be
users who would choose to skip a task simply because that task did not
interest him based on some set criteria. Some of the existing tasks
in the system at the time of the user's registration could fall under
the category of being skipped. For example, "do not do a pagg
association for all real time tasks in both init and attach". If only
attach allowed for associations to be skipped then users would not be
able to apply their criteria for existing tasks.
>
> So is the reason you suggest this just to be consistent like you said in
> your note? Or is there a use you had in mind that I didn't think of?
I'm not sure - perhaps I wasn't clear enough earlier. Does the above
make my reasoning clearer?
>
> One thing I'd say is that it isn't possible to be fully consistent with
> attach anyway. If the init function pointer fails, it isn't like we can
> propegate the error to fork like we do in attach. And I doubt we'd want to
> kill the running task :)
Absolutely ;) Full consistency isn't possible. I was only thinking
about skipping pagg associations. A failure during init would have to
be different to a failure in attach. Hence the explanation of what
happens with a <0 error return: the registration function fails but
the task is not killed.
<0 Error which is propagated back to copy_process so
the registration function fails completely.
=0 success, attach to same container as parent
>0 success, but don't attach to a container
>
> Let me know your thoughts on this...
Thanks for listening,
--
Kingsley
|