ChromeWorkers: add ability to do Unix domain socket I/O

RESOLVED FIXED

Status

()

RESOLVED FIXED
7 years ago
3 years ago

People

(Reporter: philikon, Unassigned)

Tracking

Other Branch
Points:
---

Firefox Tracking Flags

(blocking-kilimanjaro:-, blocking-basecamp:-)

Details

(Whiteboard: [soft])

Attachments

(1 attachment)

(Reporter)

Updated

7 years ago
Assignee: nobody → philipp
Can someone fixup the bug dependencies here? From that thread, if so many platform features depend on this we should definitely block on it.
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
Those features don't strictly depend on this work (they all have alternate, less clean implementations), but this work will make all of them much easier to maintain going forward.  Would recommend soft blocking.
Whiteboard: [soft]
I've marked it soft-blocking, but don't really agree.

If this is optional then we need Philipp on more important things. IMO we either need to commit here, in order to support all those apps, or commit the other way and let them ship with workarounds.
I will leave the decision up to Vincent, qDot, and ultimately cjones. I think we can put something together by the end of this week. This may help code clarity with the new stuff (Vincent's tethering, qDot's Bluetooth). With a few more days we can have the RIL and USB mounting switched over, too, I suspect.

I understand if the desire to rewrite that much code at this point is very low.
blocking-basecamp: + → -
blocking-kilimanjaro: + → -
While I'm not going to try and solve this completely right now due to time constraints, our socket implementation for bluetooth should cover 90% of what this bug will need, meaning we can either reuse or retrofit the code to finish this out after BluetoothSocket has shipped.
(In reply to Kyle Machulis [:kmachulis] [:qdot] from comment #5)
> While I'm not going to try and solve this completely right now due to time
> constraints, our socket implementation for bluetooth should cover 90% of
> what this bug will need, meaning we can either reuse or retrofit the code to
> finish this out after BluetoothSocket has shipped.

+1 on shipping Bluetooth now. I'll be happy to refactor later.
Taking this, since I already implemented ipc unix sockets for bluetooth. Using this bug to put the API philikon proposed earlier on top of it.
Assignee: philipp → kyle
Created attachment 711491 [details] [diff] [review]
wip

Here's a WIP Kyle and I threw together a while back.
Thomas, your current updates will put us closer to having sockets on workers, right?
Assignee: kyle → nobody
Flags: needinfo?(tzimmermann)
Yes. The WIP patch probably won't work any more, but workers can now support (Unix Domain) socket I/O with the classes in ipc/unixsocket. The required patches are in bug 1168806 and bug 1172479. RIL will use this feature as soon as bug 1171994 has landed.
Flags: needinfo?(tzimmermann)
Ok, just marking this resolved then.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
I'm not sure what this bug covers, but there's still no WebAPI in Gecko, just an implementation.
You need to log in before you can comment on or make changes to this bug.