Closed Bug 526361 Opened 15 years ago Closed 15 years ago

Defer "nonqueued" messages received during synchronous IPC calls

Categories

(Core :: IPC, defect)

x86
Windows NT
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bent.mozilla, Assigned: bent.mozilla)

References

Details

Attachments

(3 files, 1 obsolete file)

Attached patch Patch, v1Splinter 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.
Attached patch Patch, v2 (obsolete) — Splinter Review
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)
Attachment #410398 - Flags: review?(jmathies)
Here's the patch I used to figure out which messages we might need to handle.
Attachment #410411 - Attachment description: Debug patch for auditing sent messages → Debug patch for auditing "nonqueued" messages
ben, can you do a quick merge and repost? I can look at this today.
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 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+
IsWindow(hwnd) might be a good call to add for those hwnd operations as well.
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+
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: