>>>>> On Tue, 12 Feb 2002 11:15:54 +0000, David Howells <dhowells@redhat.com> said:
David.H> Well, I've been using them in two ways to date, without
David.H> much of a problem.
Well, that's my point. This kind of stuff works great until you
start to really push it.
David.H> The biggest problem I've seen is with
David.H> signal cancellation/alteration by the signal delivery
David.H> callback on an ornament, since that affects what signal
David.H> (and if) the next ornament sees.
Yup. And that's only the beginning. I bet the perfmon support would
introduce even more interesting ordering constraints.
David.H> There are two further callbacks I have thought about
David.H> adding:
David.H> (1) Subsumation of the pending signal-notifier stuff
David.H> currently in the task_struct (used by DRM). However, this
David.H> means the the sigmask_lock must be held any time you want
David.H> to walk or change the task ornament list:-/
David.H> (2) CPU user exception notification(s). Give task
David.H> ornaments a chance to handle these in a way more
David.H> appropriate to the binfmt or personality of the process
David.H> (for instance, to generate a Win32 structured exception).
David.H> However, I think this is probably superfluous given
David.H> the provision of the signal delivery notification.
David.H> There are also a number of other things I've thought about
David.H> trying to do with task ornaments, though I'm not sure of
David.H> how practical they are. The only one I can actually think
David.H> of at the moment, though, is:
David.H> (1) Child process notifying parent (and other processes)
David.H> on death (basically the SIGCHLD handler). This would allow
David.H> this bit of code to be removed from the exit path. A parent
David.H> process would install an ornament in each child process's
David.H> list and would remove them when the parent died. This might
David.H> make thread handling somewhat easier, as signals could then
David.H> be easily redirected.
Basically, you're proving my point. Ornaments look like a generic
facility, yet there are global dependencies (ordering, locking, ...)
which require each use to be checked against possibly all existing
ornament users.
--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 : Fri Feb 15 2002 - 21:00:50 EST