Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats

From: jamal
Date: Tue Jul 04 2006 - 09:04:36 EST


On Mon, 2006-03-07 at 18:01 -0700, Andrew Morton wrote:
> On Mon, 03 Jul 2006 20:54:37 -0400
> Shailabh Nagar <nagar@xxxxxxxxxxxxxx> wrote:
>
> > > What happens when a listener exits without doing deregistration
> > > (or if the listener attempts to register another cpumask while a current
> > > registration is still active).
> > >
> > ( Jamal, your thoughts on this problem would be appreciated)
> >
> > Problem is that we have a listener task which has "registered" with
> > taskstats and caused
> > its pid to be stored in various per-cpu lists of listeners. Later, when
> > some other task exits on a given cpu, its exit data is sent using
> > genlmsg_unicast on each pid present on that cpu's list.
> >
> > If the listener exits without doing a "deregister", its pid continues to
> > be kept around, obviously not a good thing. So we need some way of
> > detecting the situation (task is no longer listening on
> > these cpus events) that is efficient.
>
> Also need to address the case where the listener has closed off his file
> descriptor but continues to run.
>
> So hooking into listener's exit() isn't appropriate - the teardown is
> associated with the lifetime of the fd, not of the process. If we do that,
> exit() gets handled for free.

If you are always going to send unicast messages, then -ECONNREFUSED
will tell you the listener has closed their fd - this doesnt meant it
has exited. Besides that one process could open several sockets. I know
that would not be the app you would write - but it doesnt stop other
people from doing it.
I think i may not follow what you are doing - for some reason i thought
you may have many listeners in user space and these messages get
multicast to them?
Does the user space program somehow communicate its pid to the kernel?

cheers,
jamal

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/