Closed
Bug 526361
Opened 15 years ago
Closed 15 years ago
Defer "nonqueued" messages received during synchronous IPC calls
Categories
(Core :: IPC, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: bent.mozilla, Assigned: bent.mozilla)
References
Details
Attachments
(3 files, 1 obsolete file)
15.18 KB,
patch
|
Details | Diff | Splinter Review | |
6.29 KB,
patch
|
Details | Diff | Splinter Review | |
46.15 KB,
patch
|
jimm
:
review+
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
Sending all messages to DefWndProc is not great long-term. We should instead queue the messages we receive and then fake them once we get back to the event loop. Patch attached does exactly that. The windows-only code here has grown large enough that I think it should be in its own file. I'll move some stuff over to a new file in a new patch in a sec, but that introduces lots of noise. This current patch is the meat of the changes.
Assignee | ||
Comment 1•15 years ago
|
||
Ok, here's the first patch (plus a few little tweaks) moved into its own file. This cleans up SyncChannel quite a bit. The basic strategy is to grab all the messages that we process during the neutered window procedure and stuff fake runnables into an array. Then we set a hook once we leave the WaitForNotify function to run before any other messages can. That hook runs all the deferred messages and cleans up after itself. Simple! ;)
Attachment #410398 -
Flags: review?(tellrob)
Attachment #410398 -
Flags: review?(robert.bugzilla)
Assignee | ||
Updated•15 years ago
|
Attachment #410398 -
Flags: review?(jmathies)
Assignee | ||
Comment 2•15 years ago
|
||
Here's the patch I used to figure out which messages we might need to handle.
Assignee | ||
Updated•15 years ago
|
Attachment #410411 -
Attachment description: Debug patch for auditing sent messages → Debug patch for auditing "nonqueued" messages
Comment 3•15 years ago
|
||
ben, can you do a quick merge and repost? I can look at this today.
Assignee | ||
Comment 4•15 years ago
|
||
Attachment #410398 -
Attachment is obsolete: true
Attachment #412006 -
Flags: review?(tellrob)
Attachment #412006 -
Flags: review?(robert.bugzilla)
Attachment #412006 -
Flags: review?(jmathies)
Attachment #410398 -
Flags: review?(tellrob)
Attachment #410398 -
Flags: review?(robert.bugzilla)
Attachment #410398 -
Flags: review?(jmathies)
Comment 5•15 years ago
|
||
Comment on attachment 412006 [details] [diff] [review] Patch, v2, refreshed Generally the code looks good. Does this put parent stability at risk if the child misbehaves? I wonder if we should have a max queue depth in place. Also, in cases where you are re-firing deferred messages, I would not assume the window / window procedure is valid. So for example, void DeferredSendMessage::Run() { AssertWindowIsNotNeutered(hWnd); WNDPROC wndproc = reinterpret_cast<WNDPROC>(GetWindowLongPtr(hWnd, GWLP_WNDPROC)); CallWindowProc(wndproc, hWnd, message, wParam, lParam); } should check the result of GetWindowLongPtr. Other than that, looks ok to me.
Attachment #412006 -
Flags: review?(jmathies) → review+
Comment 6•15 years ago
|
||
IsWindow(hwnd) might be a good call to add for those hwnd operations as well.
Comment 7•15 years ago
|
||
Comment on attachment 412006 [details] [diff] [review] Patch, v2, refreshed Looks fine with Jim's comments taken into account.
Attachment #412006 -
Flags: review?(robert.bugzilla) → review+
Assignee | ||
Comment 8•15 years ago
|
||
Ok, I bullet-proofed everything. Thanks guys! Pushed changeset 6b3ac4cfff1c to electrolysis. robarnold, feel free to file a followup if you have any concerns.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•15 years ago
|
Attachment #412006 -
Flags: review?(tellrob)
You need to log in
before you can comment on or make changes to this bug.
Description
•