Bug 66484

Summary:	[RFC] DBus Spec: Activate all the owners of a single name
Product:	dbus	Reporter:	Chengwei Yang <chengwei.yang.cn>
Component:	core	Assignee:	Havoc Pennington <hp>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	normal
Priority:	medium	CC:	chengwei.yang.cn
Version:	1.5
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Chengwei Yang 2013-07-02 07:34:40 UTC

Copy from mail thread: http://lists.freedesktop.org/archives/dbus/2013-July/015708.html

Status of art
=============

As defined by DBus Specification
http://dbus.freedesktop.org/doc/dbus-specification.html

{quote}
[FIXME what happens if two .service files offer the same service; what
kind of error is reported, should we have a way for the client to choose
one?]
{/quote}

As implemented by reference dbus-daemon.

It load service file and register names in hash table, no duplicate
entry allowed, so if there are more than one .service file own a name,
the first returend by readdir(3) will win and be activated on demand.
That is somehow undefined which .service file will win because
readdir(3) doesn't ensure return dirent in any kind of order.

Meanwhile, we already has built-in support for multiple owners of a
name, that is owner queue. Also fully API support. So all the dbus
service providers should learned how to handle different situations
happened when acquiring a name.

Proposal to activate multiple owners of a name
=============

It's straight forward that we can do the similar thing when activating
service by name. Say there are N .service file declare that they own a
name, if none of them is running when a request coming, we should
activate them all
    * in random order?
	* in defined order? How? Can be defined by user?

To me, I think activate them in random order is reasonable, that's just
the same case when a service starting, it doesn't known if its
requesting name already owned by others. All the service providers
should already learned how to handle these situations through libdbus
API.

Comment 1 Chengwei Yang 2013-07-11 13:58:44 UTC

Currently, activation entries hash table has bus name as key and activation entry as value. For the minimal change, just change the value to a DBusList of activation entry is fine to me. Something like watch hash table in mainloop.

Meanwhile, a corresponding change to launchhelper is necessary. So it can activate all the owners of that name.

I have plan to implement this feature, need any positive comment or negative one?

Comment 2 Simon McVittie 2013-07-16 11:56:34 UTC

(In reply to comment #0)
> Say there are N .service file declare that they own a
> name, if none of them is running when a request coming, we should
> activate them all
>     * in random order?
> 	* in defined order? How? Can be defined by user?

Why is this better than only activating one?

Which concrete services/situations would benefit from this feature?

Comment 3 Chengwei Yang 2013-07-16 13:27:08 UTC

(In reply to comment #2)
> (In reply to comment #0)
> > Say there are N .service file declare that they own a
> > name, if none of them is running when a request coming, we should
> > activate them all
> >     * in random order?
> > 	* in defined order? How? Can be defined by user?
> 
> Why is this better than only activating one?
> 
> Which concrete services/situations would benefit from this feature?

First, this is trying to address the FIXME in DBus Spec

[FIXME what happens if two .service files offer the same service; what kind of error is reported, should we have a way for the client to choose one?] 

In the current implementation, only the first .service found by readdir(3) could be loaded, and readdir(3) returns dirent without any order, so it's unpredicatable which .service will win.

Given that dbus support multiple owner of name perfectly with owner queue, so all the service providers should have learned how to handle failure to own its name, so I think activate all of them looks reasonable.

Comment 4 Simon McVittie 2014-04-28 14:31:01 UTC

(In reply to comment #3)
> [FIXME what happens if two .service files offer the same service; what kind
> of error is reported, should we have a way for the client to choose one?] 
> 
> In the current implementation, only the first .service found by readdir(3)
> could be loaded, and readdir(3) returns dirent without any order, so it's
> unpredicatable which .service will win.
> 
> Given that dbus support multiple owner of name perfectly with owner queue,
> so all the service providers should have learned how to handle failure to
> own its name, so I think activate all of them looks reasonable.

No, I'm really not convinced by this. You have replaced "an arbitrarily-chosen service gets the name" with "an arbitrarily-chosen service gets the name, less efficiently".

Changing this would require there to be some advantage to the change. I'm not seeing one.

Comment 5 Simon McVittie 2014-09-11 11:23:26 UTC

I don't think this is useful. If you do, please reopen and justify why.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.