916203 - Need a "release this on the worker thread" API

Status: RESOLVED WONTFIX

(Core :: DOM: Workers, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to Kyle Huey [:khuey] ([e-mail]) 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?

Comment 2

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

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?

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(In reply to ben turner [:bent] (needinfo? encouraged) from comment #1)
> (In reply to Kyle Huey [:khuey] ([e-mail]) 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.

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

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

[Jan Varga [:janv]]

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

[Jan Varga [:janv]]

(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

[Jan Varga [:janv]]

Attachment: backup patch

Comment 8

[Nikhil Marathe [:nsm] (No longer reading bugmail, please needinfo?)]

Jan, the class NotificationRemoveFeatureAndReleaseRunnable in the Notifications patch might be useful.