Need a "release this on the worker thread" API

RESOLVED WONTFIX

Status

()

Core
DOM: Workers
RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: khuey, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

We need some sort of equivalent to NS_ProxyRelease for worker threads.  NS_ProxyRelease itself doesn't work because workers don't spin the XPCOM event loop during their lifetimes.

I imagine this would be some sort of templated function hanging off of WorkerPrivate that takes an already_AddRefed<T> and creates a subclass of WorkerControlRunnable and dispatches the event to the control queue.  We already GC from the operation callback so releasing C++ objects should be safe.
Blocks: 916893
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #0)
> We need some sort of equivalent to NS_ProxyRelease for worker threads.

What's the use case? We have some object that was created on a worker thread, sent somewhere else, and then needs to be proxy-released back on the worker thread?

That sounds kinda broken. What happens if the worker is already dead?
The use cases is stuff like Notifications, where some things need to dispatch to the main thread so permission prompts and principal checks can be done. Also dispatching events to objects owned by workers (see bug 916893 grep for WorkerNotificationObserver::Observe). The Notification object itself is owned by the worker thread, as are certain JS callbacks, but they've to be invoked from the main thread, so observers on the main thread may hold on to them. Could these main thread objects also hold the WorkerPrivate alive?
(In reply to ben turner [:bent] (needinfo? encouraged) from comment #1)
> (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #0)
> > We need some sort of equivalent to NS_ProxyRelease for worker threads.
> 
> What's the use case? We have some object that was created on a worker
> thread, sent somewhere else, and then needs to be proxy-released back on the
> worker thread?
> 
> That sounds kinda broken. What happens if the worker is already dead?

It's going to need to be a WorkerFeature or something.
Then that doesn't sounds much different from the other sync proxy stuff we have (e.g. in XHR). Maybe the use cases really don't have anything to do with NS_ProxyRelease?

Comment 5

4 years ago
It seems I need something similar for sync IDB, even a nsMainThreadPtrHolder equivalent.
I'm going to implement it and try if it works for sync IDB.

Comment 6

4 years ago
(In reply to Jan Varga [:janv] from comment #5)
> It seems I need something similar for sync IDB, even a nsMainThreadPtrHolder
> equivalent.
> I'm going to implement it and try if it works for sync IDB.

nah, it didn't help :(

Comment 7

4 years ago
Created attachment 820109 [details] [diff] [review]
backup patch
No longer blocks: 916893
Jan, the class NotificationRemoveFeatureAndReleaseRunnable in the Notifications patch might be useful.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.