Python Signal Emitter Race Condition Question

[Jim Kytola]

Thanks everyone for the help on this, but I'm not sure I follow what has
been suggested. I have been playing around tonight with connecting the
signals when I start the listener. For a simple test listener, I tried:

dbus_loop = DBusGMainLoop()
bus=dbus.SessionBus(mainloop=dbus_loop)
tbird_object = bus.get_object("org.mozilla.thunderbird.DBus" ,
'/org/mozilla/thunderbird/DBus')
interface = dbus.Interface(tbird_object, "org.mozilla.thunderbird.DBus")
interface.connect_to_signal("NewMail", new_mail_callback)

But I get the error:

dbus.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name
org.mozilla.thunderbird.DBus was not provided by any .service files

This problem is what led me down the path of connecting to the signals after
registration.

The other problem was that it was starting those that were not yet started
(for example, Rhythmbox would start if I tried to connect). I noticed the
line "You shouldn't use proxy objects just to listen to signals, since they
might activate the relevant service when created, but if you already have a
proxy object in order to call methods, it's often convenient to use it to
add signal matches too." from the dbus-python tutorial, but it wasn't clear
to me how to avoid this (by not using proxy objects).

Also, could you clarify what you mean by

"  2) request the current state that would be notified about by the signal"

What kind of request is this? I'm hoping I can figure out how to implement
what has been suggested, so it may not be a concern - I would just like to
understand what you mean by this.

Thanks again,
Jim

On 8/1/07, Havoc Pennington <hp at redhat.com> wrote:
>
> Thiago Macieira wrote:
> > Jim Kytola wrote:
> >> For full disclosure, I have another script that listens for
> >> NameOwnerChanged and when it finds the org.mozilla.thunderbird.DBus
> >> change, connects a callback function to the NewMail signal - so by
> >> successful run, I mean the callback function gets fired. It's certainly
> >> possible that my problem is on that side, but it does seem strange that
> >> I'm seeing the NewMail signal before the GetNameOwner method call in
> >> the bad run.
> >
> > This is your problem: you're waiting for the application to register.
> >
> > Don't.
> >
> > Connect the signal as soon as the listener starts. When the application
> > starts, register and emits the signal, your listener will have already
> > set everything up. In fact, it won't even need to listen for the
> > NameOwnerChanged signal.
> >
>
> To add to this a bit, whenever you connect to a signal *after* the
> emitter exists you need to use this pattern:
>
>   1) connect to signal
>   2) request the current state that would be notified about by the signal
>
> (in that order)
>
> Any API with signals must have a way to do 2) or it's broken, because an
> app can't connect race-free.
>
> But Thiago is certainly right that you need not wait for the bus name to
> exist before you match for signals on it.
>
> Havoc
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20070801/a99d36f4/attachment.html