Closed Bug 972253 Opened 10 years ago Closed 10 years ago

[Bluetooth] Move content of DBusThread.{cpp,h} to BT

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
1.4 S2 (28feb)

People

(Reporter: tzimmermann, Assigned: tzimmermann)

References

Details

Attachments

(4 files, 1 obsolete file)

DBusThread.{cpp,h} maintains state for Bluetooth, so the code should be located in the Bluetooth module itself. DBusThread.{cpp,h} can be removed afterwards.

This change also allows us to fix some problems in BluetoothDBusService::StartInternal, such as the re-initialization of an existing connection, or the concurrent setup on the I/O thread.
Depends on: 969314
Blocks: 972732
Attachment #8376128 - Flags: review?(kyle) → review+
Attachment #8376125 - Flags: review?(echou) → review+
Comment on attachment 8376126 [details] [diff] [review]
[02] Bug 972253: Cleanup Start/Stop methods in BlueZ backend

Review of attachment 8376126 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. One typo in the patch summary: " ... up the cod efor ... "

I just realized that sDBusConnection is accessed from two different threads (mostly from I/O thread but from BT thread in StartInternal()/ StopInternal()). We might need do some protection on this variable. Any suggestions, Thomas?
Attachment #8376126 - Flags: review?(echou) → review+
Hi Eric,

Thanks for the review.

> I just realized that sDBusConnection is accessed from two different threads
> (mostly from I/O thread but from BT thread in StartInternal()/
> StopInternal()). We might need do some protection on this variable. Any
> suggestions, Thomas?

Yeah, I've been thinking about this for a while and it would have been one of my next patch sets. :) Right now we need to set and clear sDBusConnection in {Start|Stop}Internal because of the reply that is signaled after these methods return. So we should move the reply to the end of each process (i.e. StartDBusConnectionTask and DeleteDBusConnection) and re-factor the functionality as follows:

 Starting:
   - setup Bluedroid and DBus connection in StartInternal (BT thread)
   - set sDBusConnection and start watching in StartDbusConnectionTask::Run (I/O thread)
   - signal success

 Stopping:
   - clear gDBusConnection (I/O)
   - clean up connection (BT)
   - delete connection in DeleteDBusConnetion::Run (I/O)
   - close Bluedroid (BT)
   - signal success

Stopping is ugly. There is no good way for telling DBus to stop watching a connection. This means that a connection can still receive DBus replies while being shut down. This seems to work right now because some of the code handles this case explicitly. The only way to fully protect us from racy shutdowns is to run the cleanup on the I/O thread. But there are calls to dbus_bus_remove_match [1] in StopInternal. These calls block if we want them to report errors. The other DBus calls should be fine. I'd suggest to remove error reporting from dbus_bus_remove_match and collapse steps 1 to 3 into one, which can run on the I/O thread.

Best regards
Thomas

[1] http://dbus.freedesktop.org/doc/api/html/group__DBusBus.html#ga6e6b98e19fa4400de7ef99c27b866b99
Comment on attachment 8376127 [details] [diff] [review]
[03] Bug 972253: Remove GetDBusConnection

Review of attachment 8376127 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks! :)
Attachment #8376127 - Flags: review?(echou) → review+
Updated commit message
Attachment #8376126 - Attachment is obsolete: true
Attachment #8378947 - Flags: review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: