Summary: | Calling waitForAndDispatchImmediately<M> on a loop fails when multiple M messages arrive simultaneously | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Wenson Hsieh <wenson_hsieh> | ||||
Component: | WebKit2 | Assignee: | Wenson Hsieh <wenson_hsieh> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | cdumez, ggaren, sabouhallawa, thorton, webkit-bug-importer | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 219091 | ||||||
Attachments: |
|
Description
Wenson Hsieh
2020-11-21 16:47:44 PST
Created attachment 414812 [details]
Patch
Comment on attachment 414812 [details]
Patch
r=me assuming the bots are happy.
Comment on attachment 414812 [details]
Patch
Thanks for the review!
Committed r270180: <https://trac.webkit.org/changeset/270180> All reviewed patches have been landed. Closing bug and clearing flags on attachment 414812 [details]. Comment on attachment 414812 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=414812&action=review > Source/WebKit/Platform/IPC/Connection.cpp:553 > + if (hasIncomingSynchronousMessage && waitForOptions.contains(WaitForOption::InterruptWaitingIfSyncMessageArrives)) { Since we needed to hold a lock while computing hasIncomingSynchronousMessage, it seems like it must be a bug to check hasIncomingSynchronousMessage after dropping the lock. Between dropping the lock and checking hasIncomingSynchronousMessage, the true value of hasIncomingSynchronousMessage may have changed (because a new incoming message may have arrived). Comment on attachment 414812 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=414812&action=review >> Source/WebKit/Platform/IPC/Connection.cpp:553 >> + if (hasIncomingSynchronousMessage && waitForOptions.contains(WaitForOption::InterruptWaitingIfSyncMessageArrives)) { > > Since we needed to hold a lock while computing hasIncomingSynchronousMessage, it seems like it must be a bug to check hasIncomingSynchronousMessage after dropping the lock. Between dropping the lock and checking hasIncomingSynchronousMessage, the true value of hasIncomingSynchronousMessage may have changed (because a new incoming message may have arrived). But I guess this is OK because there is only one IPC thread, and we are running on it, and we know that only the IPC thread adds to m_incomingMessages? (In reply to Geoffrey Garen from comment #7) > Comment on attachment 414812 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=414812&action=review > > >> Source/WebKit/Platform/IPC/Connection.cpp:553 > >> + if (hasIncomingSynchronousMessage && waitForOptions.contains(WaitForOption::InterruptWaitingIfSyncMessageArrives)) { > > > > Since we needed to hold a lock while computing hasIncomingSynchronousMessage, it seems like it must be a bug to check hasIncomingSynchronousMessage after dropping the lock. Between dropping the lock and checking hasIncomingSynchronousMessage, the true value of hasIncomingSynchronousMessage may have changed (because a new incoming message may have arrived). > > But I guess this is OK because there is only one IPC thread, and we are > running on it, and we know that only the IPC thread adds to > m_incomingMessages? 2 things: a. This is not new behavior in this patch b. Yes, it is my understanding that incoming messages only get enqueued by the IPC thread and we are on the IPC thread here. The reason we have a lock is because the main thread dequeues those messages. |