On Mon, 2006-03-07 at 18:01 -0700, Andrew Morton wrote: > On Mon, 03 Jul 2006 20:54:37 -0400 > Shailabh Nagar <[EMAIL PROTECTED]> 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 netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
