Implement self.skipWaiting() inside service workers.
Created attachment 328285 [details] Patch
Created attachment 328286 [details] Patch
Comment on attachment 328286 [details] Patch Clearing flags on attachment: 328286 Committed r225460: <https://trac.webkit.org/changeset/225460>
All reviewed patches have been landed. Closing bug.
<rdar://problem/35820007>
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?
(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.
(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.
(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.