long (25 seconds) pause when starting hal-device-manager

[John (J5) Palmieri]

Fix committed in DBus
(http://lists.freedesktop.org/archives/dbus/2006-March/004407.html).  I
should be doing a new release shortly.

On Wed, 2006-03-01 at 16:37 -0800, Artem Kachitchkine wrote:
> Thank you!
> 
> -Artem.
> 
> John (J5) Palmieri wrote:
> > I've further pinpointed the issue and we are working on resolving it in
> > dbus.  http://lists.freedesktop.org/archives/dbus/2006-March/004390.html
> > 
> > On Wed, 2006-03-01 at 18:07 -0500, John (J5) Palmieri wrote:
> >> So it seems my patch did not fix the issue.  It is really weird due to
> >> the fact we get stuck in poll once consistently and then all subsequent
> >> calls just go happily on their way after the poll times out.  It really
> >> has been a pita to debug.  I know what causes it.  We fire off an
> >> introspect under the hood and then block for it to return if a blocking
> >> call is made.  This works fine for three of the calls which introspect
> >> the bus but we block on the first introspect to HAL.  Funny thing is if
> >> we don't connect to the signals (the cause of the first three
> >> introspects) everything works fine.  Also if we block for introspect
> >> immediately, instead of waiting for a blocking call nothing bad happens.
> >> Workaround is to add result[1].block() to the end of the _Introspect
> >> method in proxies.py.  
> >>
> >> On Wed, 2006-03-01 at 11:38 -0800, Artem Kachitchkine wrote:
> >>> Hey John,
> >>>
> >>>>> I think this is a well-known problem with introspection and the python
> >>>>> bindings. John?
> >>>> I have a fix I need to commit.
> >>> Have this been committed?
> >>>
> >>> I'm seeing a much longer delay on Solaris, actually never seen it time 
> >>> out even after two hours wait. I'd rather start debugging with your fix, 
> >>> since I'm not a Python expert and it'd be a significant time investment 
> >>> for me.
> >>>
> >>>
> >>> -Artem.

-- 
John (J5) Palmieri <johnp at redhat.com>