Bug 224530

Summary: Wait until thread exits in CrossThreadTaskHandler::kill()
Product: WebKit Reporter: Sihui Liu <sihui_liu>
Component: New BugsAssignee: Sihui Liu <sihui_liu>
Status: NEW ---    
Severity: Normal CC: achristensen, beidson, benjamin, cdumez, cmarcelo, ews-watchlist, ggaren, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch ews-feeder: commit-queue-

Description Sihui Liu 2021-04-13 22:33:41 PDT
...
Comment 1 Sihui Liu 2021-04-13 23:07:39 PDT
Created attachment 425954 [details]
Patch
Comment 2 Chris Dumez 2021-04-13 23:17:05 PDT
Comment on attachment 425954 [details]
Patch

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

> Source/WTF/ChangeLog:7
> +

Please explain WHY you are making this change.
Comment 3 Sihui Liu 2021-04-14 10:18:29 PDT
Created attachment 425997 [details]
Patch
Comment 4 Sihui Liu 2021-04-14 10:18:52 PDT
(In reply to Chris Dumez from comment #2)
> Comment on attachment 425954 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=425954&action=review
> 
> > Source/WTF/ChangeLog:7
> > +
> 
> Please explain WHY you are making this change.

Added.
Comment 5 Chris Dumez 2021-04-14 10:30:09 PDT
Comment on attachment 425997 [details]
Patch

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

> Source/WebKit/NetworkProcess/IndexedDB/WebIDBServer.cpp:425
> +    CrossThreadTaskHandler::kill();

I have several concerns about this patch:
1. The verb "kill", to me, is not really associated with "wait for remaining tasks to be processed and wait for thread to exit"
2. The new code hangs the NetworkProcess's main thread on a background thread that is used for database activity (such activity likely includes going to disk). I don't think it is ever OK to hang the main thread on such operations.

I am all for making the code safe but making the code safe by hanging the main thread does not seem like a good trade-off.
Comment 6 Sihui Liu 2021-04-14 11:00:08 PDT
(In reply to Chris Dumez from comment #5)
> Comment on attachment 425997 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=425997&action=review
> 
> > Source/WebKit/NetworkProcess/IndexedDB/WebIDBServer.cpp:425
> > +    CrossThreadTaskHandler::kill();
> 
> I have several concerns about this patch:
> 1. The verb "kill", to me, is not really associated with "wait for remaining
> tasks to be processed and wait for thread to exit"

I think so too; can rename it to something like waitUntilFinished().

> 2. The new code hangs the NetworkProcess's main thread on a background
> thread that is used for database activity (such activity likely includes
> going to disk). I don't think it is ever OK to hang the main thread on such
> operations.
> 

ah, I don't think this is a big concern for database thread because WebIDBServer (the only user of CrossThreadTaskHandler for now) is removed in 2 cases:
1. it's idle, no pending tasks or IDB connection from web process. This means the kill operation should be very quick.
2. network process is about to be destroyed (NetworkProcess::didClose). I guess network process does not matter so much at this point.

> I am all for making the code safe but making the code safe by hanging the
> main thread does not seem like a good trade-off.
Comment 7 Sihui Liu 2021-04-14 11:13:15 PDT
Created attachment 426017 [details]
Patch
Comment 8 Chris Dumez 2021-04-14 14:30:08 PDT
Comment on attachment 426017 [details]
Patch

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

> Source/WTF/ChangeLog:9
> +        1. CrossThreadQueue<DataType>::waitForMessage() expects a new task before checking m_killed

CrossThreadQueue<DataType>::waitForMessage() should probably be fixed so that it checked m_killed when woken up:
- while (found == m_queue.end()) {
+ while (!m_killed && found == m_queue.end()) {
Comment 9 Radar WebKit Bug Importer 2021-04-20 22:34:14 PDT
<rdar://problem/76938794>