Closed Bug 992206 Opened 10 years ago Closed 10 years ago

[Bluetooth] Integrate BluetoothSocket into UnixSocketConsumer

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: tzimmermann, Assigned: tzimmermann)

References

Details

Attachments

(12 files, 5 obsolete files)

5.93 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
3.59 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
2.33 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
2.33 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
1.78 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
7.36 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
5.42 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
1.94 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
2.29 KB, patch
shawnjohnjr
: review+
Details | Diff | Splinter Review
3.61 KB, patch
tzimmermann
: review+
Details | Diff | Splinter Review
2.96 KB, patch
tzimmermann
: review+
Details | Diff | Splinter Review
8.12 KB, patch
tzimmermann
: review+
Details | Diff | Splinter Review
BluetoothSocket could be better integrated with UnixSocketConsumer.

This is especially true for the Bluedroid implementation, which partially duplicates the implementation of UnixSocketConsumer. The latter has moved on, but BluetoothSocket now slowly bitrotts.
To fix this bug, we should first convert |DroidSocketImpl| to have the same API as |UnixSocketImpl| and then allow to run |UnixSocketConsumer| with either.
Depends on: 992922
Depends on: 997137
Depends on: 1046109
Depends on: 1045486
Attachment #8464700 - Flags: review?(shuang)
Attachment #8464701 - Flags: review?(shuang)
Attachment #8464702 - Flags: review?(shuang)
Attachment #8464703 - Flags: review?(shuang)
Attachment #8464705 - Flags: review?(shuang)
Attachment #8464709 - Flags: review?(shuang)
Attachment #8464711 - Flags: review?(shuang)
Attachment #8464712 - Flags: review?(shuang)
Attachment #8464713 - Flags: review?(shuang)
Attachment #8464714 - Flags: review?(shuang)
Changes since v1:

  - rebased onto bug 1045486
Attachment #8464716 - Attachment is obsolete: true
Attachment #8467106 - Flags: review?(shuang)
Changes since v1:

  - rebased onto bug 1045486
Attachment #8464717 - Attachment is obsolete: true
Attachment #8467107 - Flags: review?(shuang)
Hi Shawn,

A number of cleanup patches for |BluedroidSocket|, but mostly simple stuff. This should probably land after bug 1045486. With the latter applied, I tested these patches by sending and receiving files.
Comment on attachment 8464701 [details] [diff] [review]
[02] Bug 992206: Use |SocketConsumerBase| for Bluetooth sockets

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

Overall, LGTM. I only have one question.

::: dom/bluetooth/bluedroid/BluetoothSocket.h
@@ +57,5 @@
> +  }
> +
> +  bool SendSocketData(mozilla::ipc::UnixSocketRawData* aMessage) MOZ_OVERRIDE
> +  {
> +    return SendDroidSocketData(aMessage);

Is it good to define function in header file here? Shall we move to .cpp file?
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #17)
> Comment on attachment 8464701 [details] [diff] [review]
> [02] Bug 992206: Use |SocketConsumerBase| for Bluetooth sockets
> 
> Review of attachment 8464701 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Overall, LGTM. I only have one question.
> 
> ::: dom/bluetooth/bluedroid/BluetoothSocket.h
> @@ +57,5 @@
> > +  }
> > +
> > +  bool SendSocketData(mozilla::ipc::UnixSocketRawData* aMessage) MOZ_OVERRIDE
> > +  {
> > +    return SendDroidSocketData(aMessage);
> 
> Is it good to define function in header file here? Shall we move to .cpp
> file?

I can't say, because it depends on the compiler. But the final patch [12] cleans up the interface and there will only be |SendSocketData| in the source file.
Comment on attachment 8464700 [details] [diff] [review]
[01] Bug 992206: Cleanup fields in |DroidSocketImpl|

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

|mConsumer| was been removed from constructor but  IsShutdownOnMainThread still uses it.
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #19)
> Comment on attachment 8464700 [details] [diff] [review]
> [01] Bug 992206: Cleanup fields in |DroidSocketImpl|
> 
> Review of attachment 8464700 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> |mConsumer| was been removed from constructor but  IsShutdownOnMainThread
> still uses it.

Oh, sorry, it seems later patch put mConsumer back.
Comment on attachment 8464700 [details] [diff] [review]
[01] Bug 992206: Cleanup fields in |DroidSocketImpl|

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

r=me, because the later patch put mConsumer back, I ignore this part.
Attachment #8464700 - Flags: review?(shuang) → review+
Comment on attachment 8464701 [details] [diff] [review]
[02] Bug 992206: Use |SocketConsumerBase| for Bluetooth sockets

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

::: dom/bluetooth/bluedroid/BluetoothSocket.h
@@ +57,5 @@
> +  }
> +
> +  bool SendSocketData(mozilla::ipc::UnixSocketRawData* aMessage) MOZ_OVERRIDE
> +  {
> +    return SendDroidSocketData(aMessage);

The later patch changes this part again, please ignore my comment.
Attachment #8464701 - Flags: review?(shuang) → review+
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #21)
> Comment on attachment 8464700 [details] [diff] [review]
> [01] Bug 992206: Cleanup fields in |DroidSocketImpl|
> 
> Review of attachment 8464700 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r=me, because the later patch put mConsumer back, I ignore this part.

I prefer patches to be self-contained. So this might still be worth a change to the patch. :/
Comment on attachment 8464703 [details] [diff] [review]
[04] Bug 992206: Use |SocketIOEventRunnable| for Bluetooth sockets

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

r=me, it uses SocketBase::SocketIOEventRunnable, reviewed by qDot.
Attachment #8464703 - Flags: review?(shuang) → review+
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #23)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #21)
> > Comment on attachment 8464700 [details] [diff] [review]
> > [01] Bug 992206: Cleanup fields in |DroidSocketImpl|
> > 
> > Review of attachment 8464700 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > r=me, because the later patch put mConsumer back, I ignore this part.
> 
> I prefer patches to be self-contained. So this might still be worth a change
> to the patch. :/
Ah. OK...
Comment on attachment 8464705 [details] [diff] [review]
[05] Bug 992206: Use |SocketIOReceiveRunnable| for Bluetooth sockets

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

r=me, it uses base class SocketBase::SocketIOReceiveRunnable, reviewed by qDot
Attachment #8464705 - Flags: review?(shuang) → review+
Comment on attachment 8464711 [details] [diff] [review]
[07] Bug 992206: Use |SocketIODeleteInstanceRunnable| for Bluetooth sockets

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

This patch seems not necessary, as Patch 11 totally removes ShutdownSocketTask, right?
Attachment #8464711 - Flags: review?(shuang)
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #27)
> Comment on attachment 8464711 [details] [diff] [review]
> [07] Bug 992206: Use |SocketIODeleteInstanceRunnable| for Bluetooth sockets
> 
> Review of attachment 8464711 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This patch seems not necessary, as Patch 11 totally removes
> ShutdownSocketTask, right?

Right. Writing these patches was a one-by-one process of cleaning up a detail of UnixSocketConsumer, then rebasing BluedroidSocket on top of the result. Only afterwards, i supplied the resulting patches in two different bugs for easier review. I guess [07] can be merged into [11].
(In reply to Thomas Zimmermann [:tzimmermann] [:tdz] from comment #28)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #27)
> > Comment on attachment 8464711 [details] [diff] [review]
> > [07] Bug 992206: Use |SocketIODeleteInstanceRunnable| for Bluetooth sockets
> > 
> > Review of attachment 8464711 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > This patch seems not necessary, as Patch 11 totally removes
> > ShutdownSocketTask, right?
> 
> Right. Writing these patches was a one-by-one process of cleaning up a
> detail of UnixSocketConsumer, then rebasing BluedroidSocket on top of the
> result. Only afterwards, i supplied the resulting patches in two different
> bugs for easier review. I guess [07] can be merged into [11].

I see. I think that rebasing these patches is a kind of wasting time. And I found other patches might have the same situation. Maybe we stick with current patch set would be better for you?
Yeah, we can do that as well.
Comment on attachment 8464712 [details] [diff] [review]
[08] Bug 992206: Use |SocketIOBase| for Bluetooth sockets

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

::: dom/bluetooth/bluedroid/BluetoothSocket.cpp
@@ +93,3 @@
>    {
> +    EnqueueData(aData);
> +    AddWatchers(WRITE_WATCHER, false);

Out of curiosity, we already have "AddWatchers(WRITE_WATCHER" in Connect(), why do we need to "AddWatchers(WRITE_WATCHER" again?
Attachment #8464712 - Flags: review?(shuang) → review+
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #31)
> Comment on attachment 8464712 [details] [diff] [review]
> [08] Bug 992206: Use |SocketIOBase| for Bluetooth sockets
> 
> Review of attachment 8464712 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/bluetooth/bluedroid/BluetoothSocket.cpp
> @@ +93,3 @@
> >    {
> > +    EnqueueData(aData);
> > +    AddWatchers(WRITE_WATCHER, false);
> 
> Out of curiosity, we already have "AddWatchers(WRITE_WATCHER" in Connect(),
> why do we need to "AddWatchers(WRITE_WATCHER" again?

The write watcher is installed for only _one_ instance; thus the 'false' parameter. When it fires, we check whether there is outbound data in the queue, and send it if so. And we do that whenever there is data available for sending.

If the write watcher was installed permanently, (parameter 'true') it would constantly fire while the file descriptor is writable, (almost always) even if there's no outbound data in the queue.
> The write watcher is installed for only _one_ instance; thus the 'false'
> parameter. When it fires, we check whether there is outbound data in the
> queue, and send it if so. And we do that whenever there is data available
> for sending.
> 
> If the write watcher was installed permanently, (parameter 'true') it would
> constantly fire while the file descriptor is writable, (almost always) even
> if there's no outbound data in the queue.
Oops, you're correct. I missed the 2nd parameter.
Changes since v1:

  - rebased on latest trunk
Attachment #8464700 - Attachment is obsolete: true
Attachment #8469151 - Flags: review+
Changes since v1:

  - rebased on latest trunk
Attachment #8464701 - Attachment is obsolete: true
Attachment #8469152 - Flags: review+
Changes since v2:

  - rebased on latest trunk
Attachment #8467107 - Attachment is obsolete: true
Attachment #8469153 - Flags: review+
Blocks: 1050174
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: