dbus glib + pthreads

Kees Jongenburger kees.jongenburger at gmail.com
Thu Nov 12 06:30:34 PST 2009


On Sat, Oct 31, 2009 at 12:25 AM, John Palmieri <johnp at redhat.com> wrote:
> You always need to use private connections in different threads otherwise one thread can starve the buffer or make calls to code across the thread boundary.

I am trying to understand what this mean.

is having a private connection  the same as having
a private variable and calling dbus_g_bus_get(DBUS_BUS_SYSTEM, &error);?

or do I need to go lower like here
http://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html
and call dbus_connection_open_private ?

Kind regards

>
> ----- "Kees Jongenburger" <kees.jongenburger at gmail.com> wrote:
>
>> Hello I am having difficulties using dbus in combination with a
>> threaded program.
>>
>> Basically I have two threads one where I want to listen to incoming
>> dbus calls and one thread that will call other dbus services. This
>> second thread
>> will for example also perform a long running download or call other
>> dbus services (also using glib). My main thread uses the glib main
>> loop while my second thread
>> simply performs his tasks end then dies.
>>
>> I am experiencing random crashes when in the seconds thread I start
>> performing dbus glib method calls.I am  dbus_threads_init_default but
>> clearly this is not enough
>> What else am I missing?
>>
>> -Do I have to use the same dbus connection for booth threads or not?
>> -Do I have to use a private dbus connection?
>> -Should I run two mainloops?
>>
>> I am currently quite clueless. Here is such a backtrace for example
>> 0x00007f91c0a85b6f in g_main_context_query () from
>> /usr/lib/libglib-2.0.so.0
>> (gdb) bt
>> #0  0x00007f91c0a85b6f in g_main_context_query () from
>> /usr/lib/libglib-2.0.so.0
>> #1  0x00007f91c0a8a627 in ?? () from /usr/lib/libglib-2.0.so.0
>> #2  0x00007f91c0a8adad in g_main_loop_run () from
>> /usr/lib/libglib-2.0.so.0
>> #3  0x0000000000402a13 in run_main_loop () at
>> echo_calling_service_threaded.c:202
>> #4  0x0000000000402aee in main (argc=2, argv=0x7fffc95d6738) at
>> echo_calling_service_threaded.c:234
>>
>>
>> I created sample code and "demo" that shows the problem I am
>> experiencing you can get it from
>> http://github.com/keesj/dbus_glib_pthread
>>
>> We have a EchoService that can echo strings. We also have a
>> EchoCallingService that can be called to call the
>> EchoService a certain number of time. The EchoCallingService on one
>> side accepts incomming requests to call the
>> EchoService a given number of times.
>> At the same time it will be calling the EchoService itself. We want
>> to
>> use thread to model this and want one thread that
>> listens for incoming dbus messages(this is the main thread)
>> and one thread that performs the calls to the EchoService.
>>
>>
>>
>> The flow of the calls should look something like this.
>> test/test_echo_calling_service test 1200
>>   |
>>   |
>>   |--callEcho(test,1200)->echo_calling_service_threaded(incomming
>> end)
>>                            |
>>                            |
>>                            |- start or
>> notify--->echo_calling_service_threaded(sending end)
>>   |<-----------------------|                     |
>>                                                  |
>>                                                  |--1200 times
>> echo(test)-->echo_service
>>
>>       |
>>
>> |<--------------------------|
>>
>>
>> How to test the current code:
>> 0) compile the code run make
>> 1) modify and copy the configuration file in data/
>> (echo_calling_service.conf and echo_service.conf) to
>> /etc/dbus/system.d the user name needs changing.
>> 2) run export LD_LIBRARY_PATH=alib
>> 3) start the echo_service ./echo_service -v &
>> 4) run ./echo_client and see it is possible to call the echo service
>> 10000 times witout problem
>> 5) start the echo calling service ./echo_calling_service_threaded -v
>> &
>> (possibly running this under gdb)
>> 6) start the test -> execute ./test/test_echo_calling_service test
>> 1200 a number of times
>>
>> Expected outcome the service works like charm and doesn't eat memory
>> or crash
>>
>> Actual outcome:
>> the echo_calling_service_threaded crashed in unpredictable ways
>> _______________________________________________
>> dbus mailing list
>> dbus at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dbus
>
> --
> --
> John (J5) Palmieri
> Software Engineer
> Red Hat, Inc.
>


More information about the dbus mailing list