# Nested Message Loop Mechanism

## Overview
In Chromium, the UI thread's message pump processes work in a round-robin
fashion from two primary sources: the Chrome Task Queue and the native OS
Message Queue (e.g., the Windows Message Queue). Bugs may occur when the thread
blocks and spins a nested message loop, causing re-entrancy into UI code that
destroys objects currently in use by the blocked outer stack frames.

## Mechanisms of Re-entrancy
When writing UI code, be aware of the following mechanisms that introduce
implicit nested message loops:

1.  **OS `SendMessage` (Windows):** If a `SendMessage` call crosses thread
    boundaries, the sending thread blocks until the target thread responds.
    While blocked, the OS will automatically dispatch incoming **non-queued**
    messages to the waiting thread.
    *   *Note:* Chrome tasks rely on *queued* messages, so they will not
        execute during this block. The risk comes entirely from native OS
        callbacks (e.g., window activation, focus changes, destruction)
        firing re-entrantly and calling back into Views code.
    *   Messages already on the queue will not be dispatched during these
        calls. Only sending a message directly to the thread will dispatch
        immediately.
    *   Any risk to these calls must originate from a direct `SendMessage` call
        to the HWND during a cross-thread call. When citing a direct
        `SendMessage` call as a risk, a clear code reference must be provided.
        `SendMessage` calls do not suddenly appear without a caller. In
        addition, Chrome cannot mitigate `SendMessage` calls from
        third-parties. These external callers are already running code inside
        the environment and can perform more damaging actions.
2.  **COM Synchronous Calls (Windows):** When a thread part of a single-threaded
    apartment (STA) blocks on a synchronous cross-apartment COM call, COM spins
    an internal message pump. This pump only processes messages from its
    internal RPC HWND and within a specific message range. However, if COM
    dispatches an RPC callback that re-enters Chrome code, state can still be
    mutated unexpectedly.