Calling back to a calling process after dbus_g_proxy_call_no_reply

[Braden McDaniel]

On Thu, 2008-08-14 at 01:26 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Thu, Aug 14, 2008 at 12:04 AM, Braden McDaniel <braden at endoframe.com> wrote:
> > So it would seem.
> >
> > When I look at the host process in gdb, it's camped out in __poll
> > (called from g_main_context_iterate). Any suggestions for debugging
> > this?
> >
> 
> That just means it's waiting in the main loop for something to happen,
> afaik. So maybe the problem is nothing is happening. Or whatever is
> happening isn't connected to the main loop as it should be.

As far as I can tell, nothing is happening.

So I'm wondering if there's some problem with how I'm getting the proxy
(in the hosted process). I'm using _new_for_name:

        dbus_g_proxy_new_for_name(
            VRML_CONTROL_FACTORY_GET_CLASS(control_factory)->connection,
                "org.openvrml.VrmlControlFactory",
                host_obj_path,
                "org.openvrml.VrmlControlHost");
        
"org.openvrml.VrmlControlFactory" is a name registered by the hosted
process. "host_obj_path" is an object path passed into the factory
function where the above call resides.

It occurs to me that I have a rather poor handle on when to use
_new_for_name vs. _new_for_name_owner vs. _new_for_peer. I've read the
documentation for these as well as what I could find at freedesktop.org;
but I still don't feel like I have a handle on when each of these is
appropriate. In particular, with respect to _new_for_peer, I'm not clear
on what kind of set-up I need to be able to use this.

-- 
Braden McDaniel                           e-mail: <braden at endoframe.com>
<http://endoframe.com>                    Jabber: <braden at jabber.org>