Bug 180329 – Implement self.skipWaiting() inside service workers

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Chris Dumez]

Implement self.skipWaiting() inside service workers.

[Chris Dumez]

Created attachment 328285 [details]
Patch

[Chris Dumez]

Created attachment 328286 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 328286 [details]
Patch

Clearing flags on attachment: 328286

Committed r225460: <https://trac.webkit.org/changeset/225460>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/35820007>

[youenn fablet]

View in context: https://bugs.webkit.org/attachment.cgi?id=328286&action=review

> Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp:56
> +                thread().runLoop().postTask([promise = WTFMove(promise), protectedThis = WTFMove(protectedThis)](auto&) {

I wonder what ensures thread() to be valid at that point.
Is there anything that prevents the worker to be terminated and the run loop to be stopped?

[Chris Dumez]

(In reply to youenn fablet from comment #6)
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=328286&action=review
> 
> > Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp:56
> > +                thread().runLoop().postTask([promise = WTFMove(promise), protectedThis = WTFMove(protectedThis)](auto&) {
> 
> I wonder what ensures thread() to be valid at that point.
> Is there anything that prevents the worker to be terminated and the run loop
> to be stopped?

The WorkerThread stays alive longer that the WorkerGlobalScope, which is why WorkerGlobalScope::m_thread is a WorkerThread&. I do ref the WorkerGlobalScope here so if accessing thread() should be safe AFAICT.

[youenn fablet]

(In reply to Chris Dumez from comment #7)
> (In reply to youenn fablet from comment #6)
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=328286&action=review
> > 
> > > Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp:56
> > > +                thread().runLoop().postTask([promise = WTFMove(promise), protectedThis = WTFMove(protectedThis)](auto&) {
> > 
> > I wonder what ensures thread() to be valid at that point.
> > Is there anything that prevents the worker to be terminated and the run loop
> > to be stopped?
> 
> The WorkerThread stays alive longer that the WorkerGlobalScope, which is why
> WorkerGlobalScope::m_thread is a WorkerThread&. I do ref the
> WorkerGlobalScope here so if accessing thread() should be safe AFAICT.

I might be missing something here.
I am not sure how we can guarantee that WorkerThread always stays alive longer than WorkerGlobalScope.
They have different refcounts.

Also, even if not destroyed, it seems feasible with the patch that we will post a task on a closed worker thread/message queue.
In that case, I would guess that the task will not be executed/destroyed on the worker thread. I haven't looked at how postTask/messageQueue works precisely so maybe I am misunderstanding something here. Let's discuss this in person tomorrow.

[Chris Dumez]

(In reply to youenn fablet from comment #8)
> (In reply to Chris Dumez from comment #7)
> > (In reply to youenn fablet from comment #6)
> > > View in context:
> > > https://bugs.webkit.org/attachment.cgi?id=328286&action=review
> > > 
> > > > Source/WebCore/workers/service/ServiceWorkerGlobalScope.cpp:56
> > > > +                thread().runLoop().postTask([promise = WTFMove(promise), protectedThis = WTFMove(protectedThis)](auto&) {
> > > 
> > > I wonder what ensures thread() to be valid at that point.
> > > Is there anything that prevents the worker to be terminated and the run loop
> > > to be stopped?
> > 
> > The WorkerThread stays alive longer that the WorkerGlobalScope, which is why
> > WorkerGlobalScope::m_thread is a WorkerThread&. I do ref the
> > WorkerGlobalScope here so if accessing thread() should be safe AFAICT.
> 
> I might be missing something here.
> I am not sure how we can guarantee that WorkerThread always stays alive
> longer than WorkerGlobalScope.
> They have different refcounts.
> 
> Also, even if not destroyed, it seems feasible with the patch that we will
> post a task on a closed worker thread/message queue.
> In that case, I would guess that the task will not be executed/destroyed on
> the worker thread. I haven't looked at how postTask/messageQueue works
> precisely so maybe I am misunderstanding something here. Let's discuss this
> in person tomorrow.

Filed https://bugs.webkit.org/show_bug.cgi?id=180372.