Re: Task ornaments

[David Mosberger]

>>>>> On Tue, 12 Feb 2002 11:15:54 +0000, David Howells <[e-mail]> 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