Re: [patch 1/2] fork_connector: add a fork connector

[Ram <linuxram@us.ibm.com>]

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