Thread problem causing some calls to hang for 25

[Carlsson, Johannes]

Hi Guys

At Sony Ericsson this problem was quite frequent when turning on and off Bluetooth on our Android phone (Xperia X10i mini). Sometimes this operation took ~25s extra. We also managed to reproduce the problem on a Google G1, but this was a bit harder to do. I also reproduced it very frequently by adding a delay for every 3:rd (or something) call to _dbus_connection_acquire_io_path right after the connection lock had been released (I think this was the place at least).

When looking into the code for _dbus_connection_acquire_io_path I noticed that it releases the connection lock for a while. During this period another thread might already read the response and either put it in the incoming messages queue or already flagged it as completed (depending on which thread/call that did the actual reading). In Android there are several threads accessing the dbus-library at the same time, one which is dispathing events (android_server_BluetoothEventLoop.cpp) which calls dbus_watch_handle and a number of threads that will call dbus_connection_send_with_reply (android_bluetooth_common.cpp).

I tested this solution and it fixed this problem spot on (I tested by leaving the phone over night with a special sw that turned on and off Bluetooth constantly). During this test we also found a fd leak in the Android code, but that is another story :)

Is this patch something you could consider applying?

Regards
/Johannes



>Em Segunda-feira 17 Maio 2010, às 09:46:53, Thiago Macieira escreveu:
>> Em Segunda-feira 17. Maio 2010, às 09.02.35, Redestig, Johan escreveu:
>> > Hi Guys,
>> > 
>> > As part of our Android efforts we have identified, and believe that we
>> > have a solution for a problem which causes some calls to hang for 25
>> > seconds. We uploaded a problem description and proposed solution here:
>> > https://bugs.freedesktop.org/show_bug.cgi?id=27811.
>> > 
>> > Similar problems are reported here:
>> > http://marc.info/?l=freedesktop-dbus&m=117323275932377&w=2
>> > https://bugs.freedesktop.org/show_bug.cgi?id=27533
>> > 
>> > We would really appreciate feedback on the proposed solution from the
>> > dbus experts.
>> 
>> Hi
>> 
>> The patch makes sense. I don't know if it solves the issue (I can't
>> reliably reproduce it), but I do have a bug report for Qt about a
>> threading issue. I'll see if that issue is reproducible and if the patch
>> has any impact.

>The Qt issue is http://bugreports.qt.nokia.com/browse/QTBUG-7475. I can 
>reproduce it reliably with and without the patch.
>
>So the patch doesn't fix the issue.
>
>It does make it that much rarer, though. I have another issue in a private 
>bugtracker for Maemo that shows considerable improvement. Instead of locking 
>up for 25 seconds every 10-15 attempts, it takes me more than 300 attempts to 
>get a lockup.