Messages in this thread | | | Subject | Re: [Patch][RFC] Disabling per-tgid stats on task exit in taskstats | From | jamal <> | Date | Tue, 04 Jul 2006 09:05:53 -0400 |
| |
On Mon, 2006-03-07 at 18:01 -0700, Andrew Morton wrote: > On Mon, 03 Jul 2006 20:54:37 -0400 > Shailabh Nagar <nagar@watson.ibm.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |