Ingo Molnar <mingo@redhat.com> wrote:
> i saw (and like) the ornaments stuff, and TUX could use it too: right now
> TUX has an extra field in task_struct to do exit()-time deregistering of
> processes. Linus suggested to use a more generic mechanizm. I think some
> already existing things, like the SysV semaphore exit()-time cleanup
> feature can be handled with the ornaments feature as well.
I was thinking about this, and have come up with another possible way of using
task ornaments:
What if the SIGCHLD notification mechanism used it too?:
(1) When a process forks a child, it would insert an ornament into that
child's ornament list. This ornament would points back to itself.
(2) This ornament overloads the signal and exit methods of the ornament, and
would use these to obtain notification of death signals, stop signals and
exits from the child (on which basis it can raise SIGCHLD in the parent
process).
(3) If a debugger attaches to a process, it would insert an ornament in front
of the one inserted by the parent.
(4) This ornament would allow the child's signals to be intercepted, and
would permit the following operations to be performed:
(a) raising SIGCHLD (or some other signal) in the debugger process and/or
releasing of suspended wait() calls.
(b) cancellation of the signal (so the child doesn't receive it),
(c) prevention of propagation to ornaments further along the list.
This would allow the debugger to attach _without_ reparenting the
process.
(5) If a debugger want's to follow-fork, then the fork notification method
can be overloaded in it's ornament to stick an ornament into the forked
grandchild.
(6) If the process's parent dies, then
(a) the process can be reparented to init, and the ornament can be simply
removed.
(b) the ornament can be pointed instead to another thread of the same
group.
If this is worthwhile doing, it may well be worth simplifying the notification
iteration functions to lock the task_struct, notify all ornaments (removing
those that indicate that they should be removed), drop the lock and reschedule
if necessary.
This means that a task ornament can't add more task ornaments to the same
process, but I'm not sure this matters.
It may also be worth saying that all task ornaments have to be a particular
size, and using the slab memory stuff to manage them, rather than embedding
them as I currently envisiage, particularly as there'd be quite a lot of them.
struct task_ornament {
struct task_ornament_ops *to_ops;
struct list_head *to_list;
void *to_private;
}
David
-
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/
This archive was generated by hypermail 2b29 : Thu May 31 2001 - 21:00:15 EST