race-condition using AddMatch

[Havoc Pennington]

On Tue, 2005-06-21 at 14:43 -0400, David Zeuthen wrote:
> where we evidently lose signal A because we haven't yet subscribed to
> any signals. Is this the intended behavior of the bus? 
> 
> It's not exactly bad behavior as mostly all signals on HAL represent a
> state change (e.g. disk mount/umount) and the _device_added signal
> handler should query that state (e.g. is disk mounted) after AddMatch()
> succeeds.

Right, that would be my stock answer (and it's also true for in-process
GObject or QObject signals of course)

> However. We do have signals in HAL where it doesn't make sense to
> provide the corresponding getState() method, e.g. we send a signal when
> the user presses e.g. the Power Button on the laptop. 

In that case the race is unavoidable, I would say. It's the same as
saying "your app can only find out about button presses after your app
starts up" - we aren't keeping a historical button press log.

> Consider a service streaming video through signals. We could argue (and
> frankly, I'm all for that) that this is not what D-BUS is for (indeed,
> the service should just offer direct sessions to the users instead)

Or if you used dbus for this I think you'd use method calls instead. I
guess this is similar to the problem Ross posted about.

We could have a stream primitive of some kind, perhaps, but I don't know
exactly what it would be like.

>  but
> I think this is something that should go in the FAQ / developers guide.
> Mostly because lots of people are going to make this mistake and assume
> they get all signals when they don't (e.g. we lose signal A above).

I'm all for docs of course.

> Here's another approach: Should we queue all signals until we the bus
> gets a receipt that the signal handler for a service has run? That's one
> possible solution to this problem.

That would require all signals to have handlers though, which isn't
really expected at all ...

Havoc