Re: Our (real) problems



On Tue, 4 Sep 2001, Maciej Stachowiak wrote:

> On 04Sep2001 03:55PM (-0400), Dan Winship wrote:
> > > > 	For control aggregates and out of proc. components we set the imortal
> > > > flag on the aggregate. This effectively makes ref / unrefs a no-op;
> > > > consequently ref counting has no effect. Instead we track the linc
> > > > connection on the exposed interfaces and listen for the "broken" signal
> > > > - and slave the lifecycle to the domain socket breaking.
> > > > 
> > > > 	So for the factory we terminate when all our controls die.
> > > > 
> > > 
> > > This is a good step forward (basically the same thing as the current
> > > workaround in Nautilus for this problem).
> > > 
> > > But what about out of process non-gui components, like the Evolution
> > > wombat server, or config monikers or other stuff of that sort?
> > 
> > Why, is the "broken" signal tied to X? Can't you get the same thing for
> > non-X stuff by just pinging the other side of the connection every now
> > and then? If you get an EPIPE, it's dead. The remote server doesn't even
> > need to ack the ping.
> > 
> 
> How do you know which connection holds what ref? 
> 
> I guess you could periodically check all your CORBA connections and
> quit once they have all been closed for some period of time, but this
> is sort of a weak implementation of leases from the client side.
> 

Well... the tcp connection working (or for that matter, any other socket
connection working) is not really the same as the other side still alive
and willing/able to talk to you. 

The connection staying alive is not a valid indication of server process
being alive - you can only really sort of tell that if you manage to start
a new connection to it. It is not really a good solution. At least IMHO.

> Regards,
> 
> Maciej
> 

	Sander

I haven't been vampired. You've been Weatherwaxed.


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]