Windows DBus shared memory name depends on _DEBUG?
ralf.habacker at freenet.de
Wed Sep 22 07:39:34 PDT 2010
Am 22.09.2010 12:58, schrieb Thomas Sondergaard:
> On 22-09-2010 11:57, Ralf Habacker wrote:
>> Am 22.09.2010 11:06, schrieb Thomas Sondergaard:
>> This is guaranted by the autolaunch protocol. When using autolaunch
>> procotol in session bus config, dbus-daemon server automatically select
>> a free tcp port on localhost and saves this address in the related
>> shared memory segment. If the dbus client is configured using the
>> autolaunch protocol (which is the default on configure time) it fetches
>> the recent session dbus address from the related shared memory address.
>> Now debug and release builds could run independent dbus daemons.
> I'm a little confused by your answer. Let me ask a little differently:
> Wouldn't it be best if debug and release builds using the default
> autolaunch protocol would connect to the same bus?
I think this depends on the use case. In the KDE on windows context -
where this implementation came from - this "feature" has been used to
run a release build for daily work and an independent debug build. KDE
uses dbus-daemon to start further applications and kioslaves. If there
would only one daemon, debug applications would start slaves from
release builds and vice versus, depending on which daemon has been
started first. This makes debugging much harder.
Because of this limitations the mentioned patch is used for KDE as default.
>> One solution not to use the autolaunch procotol, another (probably
>> better solution) is applying the following patches
>> They remove the release and debug distinction of the shared memory
>> address and allows the user to specific a dedicated autolaunched bus by
>> using the following bus address for the daemon and the client:
>> where term is either
>> 'install-path' to limit the bus to a specific install path or any other
>> term for other specific use cases.
>> With cmake this can be set on configure time by adding the following
> Those changes sound good to me - why aren't they part of dbus?
At least there are some specification extensions required before as
David mentioned - I will see if i can find some time in the next days.
More information about the dbus