Re: Problem with time package, struct rusage and wait3

[Igor Khavkine]

On Fri, Aug 03, 2001 at 10:58:37PM -0400, Roland McGrath wrote:
> > I was under the impression that, under normal UNIX semantics, if
> > a process fork()'s a child process, then when the child terminates
> > it will either receive a signal (SIGCHLD) or it's its call to
> > waitX() will return. In Hurd both of these events are coordinated
> > through proc. Are you saying that, it is possible for a task to
> > terminate without one of the above two events occuring, thus
> > not notifying proc?
> 
> Your mode of questioning doesn't really make sense to me.  So I will just
> give you the answer I think you need.  These parts of POSIX process
> semantics (wait, SIGCHLD) are implemented by the proc server.  Take a look
> at how that works; proc is not very complicated to read.  The proc server
> finds out that a Mach task died by receiving a dead-name notification for
> its send right to the task's control port.  This is the only means the
> microkernel provides to alert anyone that a task has died: the receive
> right inside the kernel for the task port gets destroyed by task_terminate,
> and all the same processing happens as for any destroyed port.  This
> includes delivering dead-name notifications to anyone who has requested
> them, and proc does this (see hurd/proc/mgt.c).

You mentioned that modifications to Mach were necesssary. I was trying
to see if that was actually true. So as I understand it now, if a task
dies, proc will know about it. That means it will be able to collect
statistics about it and record them in it's parent's process data
structure. Unless it is not possible to collect this information once
the notification is receive. Then some modifications to Mach will be
required.

> > Also, if we are talking about modifying the microkernel, is it worth
> > considering modifying `struct task_basic_info' or adding another kind
> > of task_info struct to get more statistal data from the kernel?
> 
> If there is something in particular you would like to collect, that would
> be fine.  Nothing of this nature has been under discussion so far, so
> you'll have to tell me what you are thinking of in specific.

The glibc defines many fields in the rusage structure. I think some
of them might be useful, like the about of memory used (shared, stack,
etc.), the number of pagefaults, number of context switches, number
of messages received and sent. Certainly it's not worth collecting
any of this information if it's detremental to performance, but if it's
not it might be useful.

Igor