On Mon, 2005-03-21 at 20:36, Evgeniy Polyakov wrote: > On Mon, 2005-03-21 at 12:52 -0800, Ram wrote: > > On Mon, 2005-03-21 at 04:48, Guillaume Thouvenin wrote: > > > ChangeLog: > > > > > > - Remove the global cn_fork_lock and replace it by a per CPU > > > counter. > > > - The processor ID has been added in the data part of the message. > > > Thus datas sent in a message are: "CPU_ID PARENT_PID CHILD_PID" > > > > > > Those modifications were done to be more scalable because, as > > > mentioned by Jesse Barnes, the global cn_fork_lock won't work well on a > > > large CPU system. > > > > > > This patch applies to 2.6.11-mm4. > > Guillaume, > > > > If a bunch of applications are listening for fork events, > > your patch allows any application to turn off the > > fork event notification? Is this the right behavior? > > > > Should'nt it turn off the fork-event notification when > > the number of listeners become zero? > > There is no number of listeners - netlink sockets provide multicast > dataflow. > [Although one can obtain that number]. > > As far as I can see, Guillaume's application is main management utility > -
Yes. agreed. But again nothing stops one of the many application listening on the multicast events from stopping the fork-events. Even though Guillame's application claims itself the main management utility, nothing stops another application from assuming the management role. I think if the the connector infrastructure provides a administrative kind of channel, (the one I mentioned in the reply to Guillame) that should help get better control on the management aspects of the event stream. RP > > it can turn on or off some feature, like "ip" can turn on or off > interfaces > without waiting when bounded processes decide to exit. > > RP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
