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

[jamal]

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/