dbus-cxx-devel — For development of dbus-cxx itself

[Dbus-cxx-devel] Array of String and Variants

[pan s. <son...@gm...>]

I do not see any example showing implementation if an object method accepts
Variants or arrays of strings.
Moreover, the dbus-cxx-xml2cpp tool do not generate proxy methods for such
type of object methods.

dbus-c++ use to support them by ::DBus::Variant and even std::map of (string
, variant).

Can anyone throw some light on this please?
Any help is highly appreciated.

thanks,
Pan Son

[Dbus-cxx-devel] How do I access properties of an Interface.

[roland r. <rro...@gm...>]

Hi,

Can someone help me understand, how I could access an Interfaces properties?
In general, I read that dbus-cxx attempts to provide high-level
dbus-binding. What are its limitation?

Given a DBus service, what things can I not do with dbus-cxx?

Thanks,
Roland

[Dbus-cxx-devel] Cannot find dbus-cxx-xml2cpp ?

[pan s. <son...@gm...>]

I installed the latest version 0.6.0 of dbus-cxx. I do not see the
executables dbus-cxx-xml2cpp and the introspect command for creating xmls.
Do I need to download them seperately? if yes, from where?

Regards,
Vink

Re: [Dbus-cxx-devel] dbus-cxx 0.6.0 released

[Rick L. V. Jr. <rvi...@cs...>]

Oliver Kowalke wrote:
> May I ask you for what reasons yout  throw exceptions as smart-pointers?
>
> thx and best regards,
> Oliver
>

Hello,

The dbus-cxx class DBus::Error wraps the dbus C struct DBusError. The
constructor takes care of calling dbus_error_init() and the destructor
takes care of dbus_error_free().

The problem with the previous implementation is that there was no
reference counting to the underlying C object, so a copy of DBus::Error
resulted in a premature dbus_error_free() of the underlying C object
because DBus::Error doesn't have a reference counting mechanism (neither
does DBusError).

The alternatives would be to add a reference counting mechanism to
DBus::Error (fairly trivial) or use the smart pointer's reference
mechanism.

I chose the latter because all the other classes in dbus-cxx should have
protected constructors with static public create() methods. This brings
DBus::Error in line with the others syntactically and uses a standardized
reference counting mechanism.

---

Rick

Re: [Dbus-cxx-devel] dbus-cxx 0.6.0 released

[Oliver K. <oli...@se...>]

May I ask you for what reasons yout  throw exceptions as smart-pointers?

thx and best regards,
Oliver

Rick L. Vinyard, Jr. schrieb:
> dbus-cxx is a C++ wrapper for the dbus library
> http://dbus-cxx.sourceforge.net
>
> ===== 0.6.0 =====
>
> This release is primarily a bug fix release. However, this resulted in
> significant changes to the error handling so I have bumped the minor
> release number.
>
> The dbus error wrapper was modified to provide smart pointers for all error
> objects. The reference counting of the smart pointers will prevent an issue
> that resulted in double freeing dbus errors in the previous error
> implementation.
>
> Errors thrown are now smart pointer instances of error objects and can be
> accessed as Error::pointer. This keeps the syntax for errors inline with the
> other smart pointers used throughout dbus-cxx.
>
> This also means that simple boolean tests such as the following are no longer
> valid:
>   Error error;
>   if (error) ...
>
> This would test the smart pointer rather than test for the error. To test
> whether an error is set you would need to test the is_set() method of
> the error class as in the following:
>   Error::pointer error;
>   if (error->is_set()) ...
>
> Thanks to Tyler Conant for hunting down the double free Error class issue.
>
> Fixed logic error in CallMessage::expects_reply()
>
> Thanks to Julien Bonjean for catching this one
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Dbus-cxx-devel mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel
>
>   

[Dbus-cxx-devel] dbus-cxx 0.6.0 released

[Rick L. V. Jr. <rvi...@cs...>]

dbus-cxx is a C++ wrapper for the dbus library
http://dbus-cxx.sourceforge.net

===== 0.6.0 =====

This release is primarily a bug fix release. However, this resulted in
significant changes to the error handling so I have bumped the minor
release number.

The dbus error wrapper was modified to provide smart pointers for all error
objects. The reference counting of the smart pointers will prevent an issue
that resulted in double freeing dbus errors in the previous error
implementation.

Errors thrown are now smart pointer instances of error objects and can be
accessed as Error::pointer. This keeps the syntax for errors inline with the
other smart pointers used throughout dbus-cxx.

This also means that simple boolean tests such as the following are no longer
valid:
  Error error;
  if (error) ...

This would test the smart pointer rather than test for the error. To test
whether an error is set you would need to test the is_set() method of
the error class as in the following:
  Error::pointer error;
  if (error->is_set()) ...

Thanks to Tyler Conant for hunting down the double free Error class issue.

Fixed logic error in CallMessage::expects_reply()

Thanks to Julien Bonjean for catching this one

Re: [Dbus-cxx-devel] DBus::Error Double Free

[Rick L. V. Jr. <rvi...@cs...>]

Hello,

I went ahead and reworked the error methods. The problem with testing
whether the error is set is that it may allocate resources, such as the
error string, but have the error code set to off. Thus it would pose a
memory leak.

Instead what is really needed is reference counting. Instead of adding
reference counting I went ahead and make the errors use smart pointers
like the rest of the library, and as a result the errors are now reference
counted and shouldn't have any issues.

I combined this with several patches that have been sent in the last month
and pushed out 0.6.0.

Tyler Conant wrote:
> I was calling a proxy method which didn't exist. The Exception which was
> thrown was causing a double free error on the destructor. The Dbus::Error
> was getting copied as it was passed down to the catch. I added a copy
> constructor which copies the DBusError name and message. It also checks to
> see if the error was already freed in the desctructor.
>
>
> diff -ru dbus-cxx-0.5.0.org/dbus-cxx/error.cpp
> dbus-cxx-0.5.0/dbus-cxx/error.cpp
> --- dbus-cxx-0.5.0.org/dbus-cxx/error.cpp    2009-09-29 13:26:15.000000000
> -0700
> +++ dbus-cxx-0.5.0/dbus-cxx/error.cpp    2010-01-18 08:20:46.000000000
> -0800
> @@ -27,6 +27,14 @@
>      dbus_error_init( &m_cobj );
>    }
>
> +  Error::Error( const Error & rhs )
> +  {
> +    dbus_error_init( &m_cobj );
> +    dbus_bool_t retVal = dbus_error_is_set(&m_cobj);
> +    if(retVal == TRUE )
> +      dbus_set_error( &m_cobj, rhs.m_cobj.name, rhs.m_cobj.message );
> +  }
> +
>    Error::Error( DBusError * cobj )
>    {
>      dbus_error_init( &m_cobj );
> @@ -61,7 +69,9 @@
>
>    Error::~Error( ) throw()
>    {
> -    dbus_error_free( &m_cobj );
> +    dbus_bool_t retVal = dbus_error_is_set(&m_cobj);
> +    if(retVal == TRUE )
> +      dbus_error_free( &m_cobj );
>    }
>
>    const char* Error::name() const
> diff -ru dbus-cxx-0.5.0.org/dbus-cxx/error.h
> dbus-cxx-0.5.0/dbus-cxx/error.h
> --- dbus-cxx-0.5.0.org/dbus-cxx/error.h    2009-05-05 15:17:50.000000000
> -0700
> +++ dbus-cxx-0.5.0/dbus-cxx/error.h    2010-01-15 14:47:32.000000000 -0800
> @@ -55,6 +55,8 @@
>
>        Error();
>
> +      Error( const Error & rhs );
> +
>        Error( DBusError* cobj );
>
>        Error( const char* name, const char* message=NULL );
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> Dbus-cxx-devel mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel
>

[Dbus-cxx-devel] DBus::Error Double Free

[Tyler C. <tc...@ta...>]

I was calling a proxy method which didn't exist. The Exception which was thrown was causing a double free error on the destructor. The Dbus::Error was getting copied as it was passed down to the catch. I added a copy constructor which copies the DBusError name and message. It also checks to see if the error was already freed in the desctructor.


diff -ru dbus-cxx-0.5.0.org/dbus-cxx/error.cpp dbus-cxx-0.5.0/dbus-cxx/error.cpp
--- dbus-cxx-0.5.0.org/dbus-cxx/error.cpp    2009-09-29 13:26:15.000000000 -0700
+++ dbus-cxx-0.5.0/dbus-cxx/error.cpp    2010-01-18 08:20:46.000000000 -0800
@@ -27,6 +27,14 @@
     dbus_error_init( &m_cobj );
   }

+  Error::Error( const Error & rhs )
+  {
+    dbus_error_init( &m_cobj );
+    dbus_bool_t retVal = dbus_error_is_set(&m_cobj);
+    if(retVal == TRUE )
+      dbus_set_error( &m_cobj, rhs.m_cobj.name, rhs.m_cobj.message );
+  }
+
   Error::Error( DBusError * cobj )
   {
     dbus_error_init( &m_cobj );
@@ -61,7 +69,9 @@

   Error::~Error( ) throw()
   {
-    dbus_error_free( &m_cobj );
+    dbus_bool_t retVal = dbus_error_is_set(&m_cobj);
+    if(retVal == TRUE )
+      dbus_error_free( &m_cobj );
   }

   const char* Error::name() const
diff -ru dbus-cxx-0.5.0.org/dbus-cxx/error.h dbus-cxx-0.5.0/dbus-cxx/error.h
--- dbus-cxx-0.5.0.org/dbus-cxx/error.h    2009-05-05 15:17:50.000000000 -0700
+++ dbus-cxx-0.5.0/dbus-cxx/error.h    2010-01-15 14:47:32.000000000 -0800
@@ -55,6 +55,8 @@

       Error();

+      Error( const Error & rhs );
+
       Error( DBusError* cobj );

       Error( const char* name, const char* message=NULL );

[Dbus-cxx-devel] OS X support

[Tyler C. <tc...@ta...>]

I'm thinking about adding OS X support for this project. The immediate issue I run into when compiling is the use of timer_t. OS X doesn't support the TMR option of POSIX. One of the options would be to use the asio library from boost. Does anyone have any thoughts on this matter. It would probably mean not using signals but rather a separate thread to handle timers.

Re: [Dbus-cxx-devel] Problem with expects_reply in 0.5.0

[Rick L. V. Jr. <rvi...@cs...>]

You're right. I'll fix it in the next release.


Julien Bonjean wrote:
> Hi,
> I'm using 0.5.0 version and I think I found a bug in the CallMessage
> class. The method expects_reply() currently return the value of
> dbus_message_get_no_reply. But the DBus API documentation explains that
> dbus_message_get_no_reply function returns TRUE if the message does not
> expect a reply. So expects_reply() method should be modified to :
> bool CallMessage::expects_reply() const
> {
>      if ( m_cobj == NULL ) return false;
>      return !dbus_message_get_no_reply( m_cobj );
> }
> Regards,
>
> Julien Bonjean

Re: [Dbus-cxx-devel] Patch to support vector of structures

[Rick L. V. Jr. <rvi...@cs...>]

Never mind. I see what you mean.

You overloaded the global << operator. That does make it more powerful.

I'll incorporate the change in the next release (coming soon probably).

Tyler Conant wrote:
> Thanks for incorporating that so quickly. Let me explain why I changed it
> from append to the overloaded "<< operator". My DBus interface needed to
> exposes a method with a structure for a return value.
> This structure had a couple of vectors of structures. I overloaded the "<<
> operator" for the return value structure as well as the structures for
> each vector type. When the vectors were being appended by the
> MessageAppendIterator it was calling Append on the structure, but of
> course it wasn't defined for my structure type. Changing it from append
> allowed me to create a "<< overload " for my structure.
>
> If I'm approaching this problem incorrectly please let me know (I'm new to
> this). I didn't see any examples where there was a vector of user defined
> structures so I tried to follow the existing design pattern.
>
>
> On 1/4/10 8:03 AM, "Rick L. Vinyard, Jr." <rvi...@cs...> wrote:
>
> Tyler Conant wrote:
>> 1. This is a diff against 0.5.0. The sub iter was not being set to NULL
>> during the deletion of the iter when closing the container.  This was
>> causing an access error when creating a second child container.
>>
>
> I just pushed out 0.5.1 that fixes this bug. Thanks again for hunting this
> one down.
>
>> 2. To support structures the << operator is overloaded, but this did not
>> help with a vector of structures since the append operator was called on
>> the child iter, instead of the << operator. This change doesn't appear
>> to
>> have any side effects, but I'm new to dbus-cxx and have yet to walk
>> through the entire code base.
>>
>
> -          m_subiter->append( v[i] );
> -
> +          //m_subiter->append( v[i] );
> +                       *m_subiter << v[i];
>
> This one I'm not too clear on. I'm wondering if there is also something
> else going on.
>
> The overloaded << operator is very thin and is essentially:
>         this->append( v );
>
> As a result,
>         m_subiter->append(v[i]);
> and
>         *m_subiter << v[i];
> should be equivalent unless there is something subtle going on in the
> resolution.
>
> ---
>
> Rick
>
>
>
>

Re: [Dbus-cxx-devel] Patch to support vector of structures

[Rick L. V. Jr. <rvi...@cs...>]

You should be able to overload the append() method similarly.

I keep saying that I'm going to get the structure code working again in
the next release, but then the next release comes out and I save it for
the next one.

But, at some point in the future there will be support for structures.

Tyler Conant wrote:
> Thanks for incorporating that so quickly. Let me explain why I changed it
> from append to the overloaded "<< operator". My DBus interface needed to
> exposes a method with a structure for a return value.
> This structure had a couple of vectors of structures. I overloaded the "<<
> operator" for the return value structure as well as the structures for
> each vector type. When the vectors were being appended by the
> MessageAppendIterator it was calling Append on the structure, but of
> course it wasn't defined for my structure type. Changing it from append
> allowed me to create a "<< overload " for my structure.
>
> If I'm approaching this problem incorrectly please let me know (I'm new to
> this). I didn't see any examples where there was a vector of user defined
> structures so I tried to follow the existing design pattern.
>
>
> On 1/4/10 8:03 AM, "Rick L. Vinyard, Jr." <rvi...@cs...> wrote:
>
> Tyler Conant wrote:
>> 1. This is a diff against 0.5.0. The sub iter was not being set to NULL
>> during the deletion of the iter when closing the container.  This was
>> causing an access error when creating a second child container.
>>
>
> I just pushed out 0.5.1 that fixes this bug. Thanks again for hunting this
> one down.
>
>> 2. To support structures the << operator is overloaded, but this did not
>> help with a vector of structures since the append operator was called on
>> the child iter, instead of the << operator. This change doesn't appear
>> to
>> have any side effects, but I'm new to dbus-cxx and have yet to walk
>> through the entire code base.
>>
>
> -          m_subiter->append( v[i] );
> -
> +          //m_subiter->append( v[i] );
> +                       *m_subiter << v[i];
>
> This one I'm not too clear on. I'm wondering if there is also something
> else going on.
>
> The overloaded << operator is very thin and is essentially:
>         this->append( v );
>
> As a result,
>         m_subiter->append(v[i]);
> and
>         *m_subiter << v[i];
> should be equivalent unless there is something subtle going on in the
> resolution.
>
> ---
>
> Rick
>
>
>
>

Re: [Dbus-cxx-devel] Patch to support vector of structures

[Tyler C. <tc...@ta...>]

Thanks for incorporating that so quickly. Let me explain why I changed it from append to the overloaded "<< operator". My DBus interface needed to exposes a method with a structure for a return value.
This structure had a couple of vectors of structures. I overloaded the "<< operator" for the return value structure as well as the structures for each vector type. When the vectors were being appended by the MessageAppendIterator it was calling Append on the structure, but of course it wasn't defined for my structure type. Changing it from append allowed me to create a "<< overload " for my structure.

If I'm approaching this problem incorrectly please let me know (I'm new to this). I didn't see any examples where there was a vector of user defined structures so I tried to follow the existing design pattern.


On 1/4/10 8:03 AM, "Rick L. Vinyard, Jr." <rvi...@cs...> wrote:

Tyler Conant wrote:
> 1. This is a diff against 0.5.0. The sub iter was not being set to NULL
> during the deletion of the iter when closing the container.  This was
> causing an access error when creating a second child container.
>

I just pushed out 0.5.1 that fixes this bug. Thanks again for hunting this
one down.

> 2. To support structures the << operator is overloaded, but this did not
> help with a vector of structures since the append operator was called on
> the child iter, instead of the << operator. This change doesn't appear to
> have any side effects, but I'm new to dbus-cxx and have yet to walk
> through the entire code base.
>

-          m_subiter->append( v[i] );
-
+          //m_subiter->append( v[i] );
+                       *m_subiter << v[i];

This one I'm not too clear on. I'm wondering if there is also something
else going on.

The overloaded << operator is very thin and is essentially:
        this->append( v );

As a result,
        m_subiter->append(v[i]);
and
        *m_subiter << v[i];
should be equivalent unless there is something subtle going on in the
resolution.

---

Rick

[Dbus-cxx-devel] Arrays and dictionaries

[Julien B. <ju...@bo...>]

  Hi,
We would like to use dbus-cxx for our softphone SFLphone 
(http://sflphone.org) but it seems that support for arrays and 
dictionaries is missing (at least when using xml2cpp). Is there any plan 
to fully support them ?
Best regards,

Julien Bonjean

Re: [Dbus-cxx-devel] Patch to support vector of structures

[Rick L. V. Jr. <rvi...@cs...>]

Tyler Conant wrote:
> 1. This is a diff against 0.5.0. The sub iter was not being set to NULL
> during the deletion of the iter when closing the container.  This was
> causing an access error when creating a second child container.
>

I just pushed out 0.5.1 that fixes this bug. Thanks again for hunting this
one down.

> 2. To support structures the << operator is overloaded, but this did not
> help with a vector of structures since the append operator was called on
> the child iter, instead of the << operator. This change doesn't appear to
> have any side effects, but I'm new to dbus-cxx and have yet to walk
> through the entire code base.
>

-          m_subiter->append( v[i] );
-
+          //m_subiter->append( v[i] );
+			*m_subiter << v[i];

This one I'm not too clear on. I'm wondering if there is also something
else going on.

The overloaded << operator is very thin and is essentially:
        this->append( v );

As a result,
        m_subiter->append(v[i]);
and
        *m_subiter << v[i];
should be equivalent unless there is something subtle going on in the
resolution.

---

Rick

[Dbus-cxx-devel] dbus-cxx 0.5.1 released

[Rick L. V. Jr. <rvi...@cs...>]

dbus-cxx is a C++ wrapper for the dbus library
http://dbus-cxx.sourceforge.net

===== 0.5.1 =====
This release fixes a bug in the append iterator when
a second child container is used. Thanks to Tyler Conant
for hunting this one down.

Re: [Dbus-cxx-devel] Patch to support vector of structures

[Rick L. V. Jr. <rvi...@cs...>]

Thanks. I'll get it added and a new release out.

Tyler Conant wrote:
> 1. This is a diff against 0.5.0. The sub iter was not being set to NULL
> during the deletion of the iter when closing the container.  This was
> causing an access error when creating a second child container.
>
> 2. To support structures the << operator is overloaded, but this did not
> help with a vector of structures since the append operator was called on
> the child iter, instead of the << operator. This change doesn't appear to
> have any side effects, but I'm new to dbus-cxx and have yet to walk
> through the entire code base.
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Dbus-cxx-devel mailing list
> Dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cxx-devel
>

[Dbus-cxx-devel] Problem with expects_reply in 0.5.0

[Julien B. <ju...@bo...>]

Hi,
I'm using 0.5.0 version and I think I found a bug in the CallMessage 
class. The method expects_reply() currently return the value of 
dbus_message_get_no_reply. But the DBus API documentation explains that 
dbus_message_get_no_reply function returns TRUE if the message does not 
expect a reply. So expects_reply() method should be modified to :
bool CallMessage::expects_reply() const
{
     if ( m_cobj == NULL ) return false;
     return !dbus_message_get_no_reply( m_cobj );
}
Regards,

Julien Bonjean

[Dbus-cxx-devel] still races with 0.5.0

[Oliver K. <oli...@se...>]

Hi,
I've tested version 0.5.0 with a simple multithreaded echo app (server 
+client). It still contains races: sometimes the client is block in receiving 
the response (gets unblocked after certain time -> seams to be a timeout 
unblocks it). The server remains still responsible.

best regards,
Oliver

[Dbus-cxx-devel] dbus-cxx 0.5.0 released

[Rick L. V. Jr. <rvi...@cs...>]

dbus-cxx is a C++ wrapper for the dbus library
http://dbus-cxx.sourceforge.net

===== 0.5.0 =====
This release has some new features, some bug fixes and some added support for
older versions of GCC and dbus, and new Ubuntu builds on Launchpad.

One of the new features is preliminary support for arrays of fixed types. An
example can be found in the signal examples directory and the two example
programs are name signal_emitter_array and signal_receiver_array.

Many of the template functions have been changed and are now generated by
M4 to support older versions of GCC that don't recognize default template
function parameters.

Checks have been added and conditional code added to allow building
against dbus 1.1 (and possibly dbus 1.0; only dbus 1.1 was tested). This
change, combined with the GCC support changes, mean that dbus-cxx can
now be compiled on RHEL 5. Builds will be available in Fedora shortly
for the EPEL 5 (RHEL 5, CentOS 5) family.

Finally, there are numerous minor bug cleanups which should significantly
reduce the amount of compile warnings generated.

[Dbus-cxx-devel] Ubuntu Launchpad PPA

[Rick L. V. Jr. <rvi...@cs...>]

I have set up an Ubuntu Launchpad PPA with builds of the latest dbus-cxx
for Jaunty on i386, amd64 and lpia.

More info on the dbus-cxx project page: http://dbus-cxx.sourceforge.net

Re: [Dbus-cxx-devel] Some potential backward compatibility patches

[Rick L. V. Jr. <rvi...@cs...>]

Ramin Yaghoubzadeh wrote:
> Please consider them to increase backwards compatibility with older
> gccs, a.k.a. those running in "stable" workgroup setups, and on OSX :)
> They enabled me to build dbus-cxx on our old gcc-4.2 Ubuntu hardy.

Sounds good. I'll try and get them worked into the next release.

[Dbus-cxx-devel] Some potential backward compatibility patches

[<rya...@Te...>]

Hi again,
after today having dbus-cxx croak on "make" with gcc-4.2 after I tried
using my program at work (I use gcc-4.3 / gcc-4.4 at home), I made
these fixes for (slightly) older gcc versions.

dbus_cxx_configure.in_gcc_4.2_compat.patch
changes configure.in to additionally allow for the different includes
for tr1 in gcc-4.2 (as opposed to 4.1 which the current tr1 shared
pointer mode seemed to be based on)

dbus_cxx_tr1_smartpointers_for_gcc_4.2.patch
does the same for dbus-cxx/pointer.h

dbus_cxx_remove_default_template_arguments_for_gcc_le_4.2.patch
is simply an expansion of the "=nil" default template arguments in
several .h headers / .h.m4 headers, which seem not to be allowed
at all before gcc-4.3. I have #if'fed the defaulted version in for
newer gccs, although the expanded version would suffice, I assume?

Please consider them to increase backwards compatibility with older
gccs, a.k.a. those running in "stable" workgroup setups, and on OSX :)
They enabled me to build dbus-cxx on our old gcc-4.2 Ubuntu hardy.

Regards,
  Ramin

Re: [Dbus-cxx-devel] rwlock fix (I think?)

[Rick L. V. Jr. <rvi...@cs...>]

You're right. There are a handful of uninitialized mutexes and undestroyed
pthread items.

Patrick Allison provided an earlier patch that seems to incorporate all of
them plus fixed a deadlock issue.

The new release (0.4.3) incorporates Patrick's work. I also reordered
several of the name mutex locks/unlocks to prevent the signal callbacks
from potentially causing deadlocks.

Ramin Yaghoubzadeh wrote:
> Hi,
>
> I've been trying dbus-cxx, and I was quite pleased with its design. Then I
> hit random deadlocks of my D-Bus, which I wasted quite some time on before
> I enabled debug loggin in the lib (and added more debug messages).
>
> It seems object.cpp and objectproxy.cpp did not yet initialize their
> interface rwlocks (unless I misunderstood), including the current SVN.
> I am attaching the patch (2 lines) which fixed everything for me :)
>
> Best wishes, and thanks a lot so far for this library :)
> 	Ramin
>

[Dbus-cxx-devel] rwlock fix (I think?)

[<rya...@Te...>]

Hi,

I've been trying dbus-cxx, and I was quite pleased with its design. Then I
hit random deadlocks of my D-Bus, which I wasted quite some time on before
I enabled debug loggin in the lib (and added more debug messages).

It seems object.cpp and objectproxy.cpp did not yet initialize their
interface rwlocks (unless I misunderstood), including the current SVN.
I am attaching the patch (2 lines) which fixed everything for me :)

Best wishes, and thanks a lot so far for this library :)
	Ramin