[bluetooth] Replace IPC channel with GenericChannel

[wusyong]

Describe the new feature: With #32339, Servo now has a generic channel that can select different channel implementation during runtime. This can help servo to use ipc channel if it's in multiprocess mode, and crossbeam channel if not.

There are lost of places that ipc::channel is used. Let's start with Bluetooth crate first since it only has two calls:

• [ ] Replace impl BluetoothThreadFactory for IpcSender<BluetoothRequest> with impl BluetoothThreadFactory for GenericSender<BluetoothRequest> instead
• [ ] Replace GetSelectedBluetoothDevice(Vec<String>, IpcSender<Option<String>>) with GetSelectedBluetoothDevice(Vec<String>, GenericSender<Option<String>>)

Feel free to take one of them above and open the PRs. Or if you are interested in more other crates, open more issues like this. I'll also open some more in the future.

[wusyong]

@sagudev I couldn't add any label yet. Could you add B-newcomer to it?

[wusyong]

Hmm, after looking a bit more into GetSelectedBluetoothDevice, it doesn't seem to cross to the content process or service worker. Perhaps it can just be a crossbeam channel.

[sagudev]

Hmm, after looking a bit more into GetSelectedBluetoothDevice, it doesn't seem to cross to the content process or service worker. Perhaps it can just be a crossbeam channel.

We would likely want to move Bluetooth out of content process for security reasons in the future.

[mrobinson]

I'm not sure we should replace every use of ipc::channel with GenericChannel. There are times that it is really useful to know what kind of channel you are dealing with and abstracting that away makes things a bit confusing.

[mrobinson]

Proposal: For now use this for situations when we need to write code that needs to communicate both in-process and out-of-process.

[wusyong]

Proposal: For now use this for situations when we need to write code that needs to communicate both in-process and out-of-process.

I'm not going to replace all ipc::channel. There are places will use more tools other than just sender and receiver. I think it will be difficult to unify those usages in GenericChannel.

For Bluetooth crate, it makes sense to refactor BluetoothThreadFactory because it needs to communicate both in and out of the process. And it seems GetSelectedBluetoothDevice will stay in-process only. I'll open future issues for only those who have both in-process and out-of-process communication.

[lwz23]

This sounds like a problem related to rust generics, perhaps not too hard, and I want to try to deal with it.

[willypuzzle]

Can I try this?

[sagudev]

Can I try this?

I think it was decide that this will not be done per https://github.com/servo/servo/issues/32411#issuecomment-2405681547, but I might be wrong.

[wusyong]

Sorry I should have closed this issue already. We've decided not to do this.