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

Ram
2005-03-22T18:44:24Z

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