Re: stale IORs in lock directory ...

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael ximian com> writes:
> 
> 	Just looking at gconf HEAD, I have a couple of queries:
> 
> 	firsty we do:
> 
>   daemon_lock = gconf_get_lock_or_current_holder (lock_dir,
>                                                   &other_server,
>                                                   &err);
> 
> 	Then if other_server != CORBA_OBJECT_NIL we register it with oaf,
> and then quit. Problem is - it's highly likely that other_server is a
> valid stringified IOR, but actualy the object doesn't exist.

Are you considering that I ping the existing lock holder by invoking
the _ping() method on it?

                      ConfigServer_ping(server, &ev);
      
                      if (ev._major != CORBA_NO_EXCEPTION)
                        {
                          gconf_log(GCL_WARNING, _("Removing stale
                        lock `%s' because of error pinging server:
                        %s"),
                                    lock->lock_directory,
                        CORBA_exception_id(&ev));
                          CORBA_exception_free(&ev);
                          stale = TRUE;
                          got_it = TRUE;
                          goto out;
 
> 	However - then we need to shove our IOR into the lock_dir, in
> which case it seems to me ( and if other_server == CORBA_OBJECT_NIL -
> although this will perhaps never happen ), that we need to take the lock
> and continue starting up - or we'll never activate another daemon.
> 

I'm not sure I've figured out which code path you're describing -
you're saying that if a server exists and we pass the old one to oaf,
it doesn't end up owning the lock? Didn't it already have the lock?

This whole mess is just a workaround for OAF "losing" gconfd anyhow,
so I wish it could go away.

Havoc