Re: Deadlock?

[Havoc Pennington <hp redhat com>]

Dietmar Maurer <dietmar ximian com> writes:
> Havoc Pennington wrote:
> 
> > Darin Adler <darin eazel com> writes:
> > > I am starting Nautilus and it hangs.
> > >
> > > I find that it is waiting for a reply for the CORBA call
> > > ConfigServer_add_client. I assume the ConfigServer in question is an object
> > > whose server is the gconfd process.
> > >
> > > So I fire up gdb and attach to gconfd to see what the daemon is doing. It is
> > > waiting for an outgoing connection to do a ConfigListener_update_listener
> > > outgoing CORBA call. I'm guessing that the listener is an object whose
> > > server is the nautilus process.
> > >
> > > This seems like a classic case of deadlock to me. But I'm assuming that
> > > GConf is designed to avoid such problems and some other bug is leading to
> > > this problem.
> > >
> > > Can you help me Havoc?
> >
> > update_listener is oneway. My understanding is that this means the
> > call isn't supposed to block waiting on the client, so there shouldn't
> > be a deadlock. So that's what's supposed to happen.
> 
> I thought "oneway" only says that you can't rely on message delivery, it does
> not state something about server behavior?
> 

I think here I was relying on Elliot telling me that in ORBit oneway
always meant we wouldn't block. I don't care about the CORBA spec,
because CORBA is an implementation detail of GConf and it always uses
ORBit.

If oneway blocks in any case whatsoever, GConf falls apart entirely;
because anytime you change a key it can try to notify clients, and one
hosed client would hang gconfd, and then any client trying to access
gconfd would hang, and shortly the whole desktop is hosed due to any
application being hosed.

i.e. notification (and update_listener) CANNOT have the possibility of
hanging gconfd. If oneway doesn't work here we have to drop CORBA as
our IPC mechanism. But then we are hosed.

So, anyway, if oneway blocks with ORBit we are hosed. Short answer.

Havoc