ipc/chromium/src/base/message_pump_win.h

Wed, 31 Dec 2014 06:09:35 +0100

author
Michael Schloh von Bennewitz <michael@schloh.com>
date
Wed, 31 Dec 2014 06:09:35 +0100
changeset 0
6474c204b198
permissions
-rw-r--r--

Cloned upstream origin tor-browser at tor-browser-31.3.0esr-4.5-1-build1
revision ID fc1c9ff7c1b2defdbc039f12214767608f46423f for hacking purpose.

michael@0 1 // Copyright (c) 2006-2008 The Chromium Authors. All rights reserved.
michael@0 2 // Use of this source code is governed by a BSD-style license that can be
michael@0 3 // found in the LICENSE file.
michael@0 4
michael@0 5 #ifndef BASE_MESSAGE_PUMP_WIN_H_
michael@0 6 #define BASE_MESSAGE_PUMP_WIN_H_
michael@0 7
michael@0 8 #include <windows.h>
michael@0 9
michael@0 10 #include <list>
michael@0 11
michael@0 12 #include "base/lock.h"
michael@0 13 #include "base/message_pump.h"
michael@0 14 #include "base/observer_list.h"
michael@0 15 #include "base/scoped_handle.h"
michael@0 16 #include "base/time.h"
michael@0 17
michael@0 18 namespace base {
michael@0 19
michael@0 20 // MessagePumpWin serves as the base for specialized versions of the MessagePump
michael@0 21 // for Windows. It provides basic functionality like handling of observers and
michael@0 22 // controlling the lifetime of the message pump.
michael@0 23 class MessagePumpWin : public MessagePump {
michael@0 24 public:
michael@0 25 // An Observer is an object that receives global notifications from the
michael@0 26 // MessageLoop.
michael@0 27 //
michael@0 28 // NOTE: An Observer implementation should be extremely fast!
michael@0 29 //
michael@0 30 class Observer {
michael@0 31 public:
michael@0 32 virtual ~Observer() {}
michael@0 33
michael@0 34 // This method is called before processing a message.
michael@0 35 // The message may be undefined in which case msg.message is 0
michael@0 36 virtual void WillProcessMessage(const MSG& msg) = 0;
michael@0 37
michael@0 38 // This method is called when control returns from processing a UI message.
michael@0 39 // The message may be undefined in which case msg.message is 0
michael@0 40 virtual void DidProcessMessage(const MSG& msg) = 0;
michael@0 41 };
michael@0 42
michael@0 43 // Dispatcher is used during a nested invocation of Run to dispatch events.
michael@0 44 // If Run is invoked with a non-NULL Dispatcher, MessageLoop does not
michael@0 45 // dispatch events (or invoke TranslateMessage), rather every message is
michael@0 46 // passed to Dispatcher's Dispatch method for dispatch. It is up to the
michael@0 47 // Dispatcher to dispatch, or not, the event.
michael@0 48 //
michael@0 49 // The nested loop is exited by either posting a quit, or returning false
michael@0 50 // from Dispatch.
michael@0 51 class Dispatcher {
michael@0 52 public:
michael@0 53 virtual ~Dispatcher() {}
michael@0 54 // Dispatches the event. If true is returned processing continues as
michael@0 55 // normal. If false is returned, the nested loop exits immediately.
michael@0 56 virtual bool Dispatch(const MSG& msg) = 0;
michael@0 57 };
michael@0 58
michael@0 59 MessagePumpWin() : have_work_(0), state_(NULL) {}
michael@0 60 virtual ~MessagePumpWin() {}
michael@0 61
michael@0 62 // Add an Observer, which will start receiving notifications immediately.
michael@0 63 void AddObserver(Observer* observer);
michael@0 64
michael@0 65 // Remove an Observer. It is safe to call this method while an Observer is
michael@0 66 // receiving a notification callback.
michael@0 67 void RemoveObserver(Observer* observer);
michael@0 68
michael@0 69 // Give a chance to code processing additional messages to notify the
michael@0 70 // message loop observers that another message has been processed.
michael@0 71 void WillProcessMessage(const MSG& msg);
michael@0 72 void DidProcessMessage(const MSG& msg);
michael@0 73
michael@0 74 // Like MessagePump::Run, but MSG objects are routed through dispatcher.
michael@0 75 void RunWithDispatcher(Delegate* delegate, Dispatcher* dispatcher);
michael@0 76
michael@0 77 // MessagePump methods:
michael@0 78 virtual void Run(Delegate* delegate) { RunWithDispatcher(delegate, NULL); }
michael@0 79 virtual void Quit();
michael@0 80
michael@0 81 protected:
michael@0 82 struct RunState {
michael@0 83 Delegate* delegate;
michael@0 84 Dispatcher* dispatcher;
michael@0 85
michael@0 86 // Used to flag that the current Run() invocation should return ASAP.
michael@0 87 bool should_quit;
michael@0 88
michael@0 89 // Used to count how many Run() invocations are on the stack.
michael@0 90 int run_depth;
michael@0 91 };
michael@0 92
michael@0 93 virtual void DoRunLoop() = 0;
michael@0 94 int GetCurrentDelay() const;
michael@0 95
michael@0 96 ObserverList<Observer> observers_;
michael@0 97
michael@0 98 // The time at which delayed work should run.
michael@0 99 TimeTicks delayed_work_time_;
michael@0 100
michael@0 101 // A boolean value used to indicate if there is a kMsgDoWork message pending
michael@0 102 // in the Windows Message queue. There is at most one such message, and it
michael@0 103 // can drive execution of tasks when a native message pump is running.
michael@0 104 LONG have_work_;
michael@0 105
michael@0 106 // State for the current invocation of Run.
michael@0 107 RunState* state_;
michael@0 108 };
michael@0 109
michael@0 110 //-----------------------------------------------------------------------------
michael@0 111 // MessagePumpForUI extends MessagePumpWin with methods that are particular to a
michael@0 112 // MessageLoop instantiated with TYPE_UI.
michael@0 113 //
michael@0 114 // MessagePumpForUI implements a "traditional" Windows message pump. It contains
michael@0 115 // a nearly infinite loop that peeks out messages, and then dispatches them.
michael@0 116 // Intermixed with those peeks are callouts to DoWork for pending tasks, and
michael@0 117 // DoDelayedWork for pending timers. When there are no events to be serviced,
michael@0 118 // this pump goes into a wait state. In most cases, this message pump handles
michael@0 119 // all processing.
michael@0 120 //
michael@0 121 // However, when a task, or windows event, invokes on the stack a native dialog
michael@0 122 // box or such, that window typically provides a bare bones (native?) message
michael@0 123 // pump. That bare-bones message pump generally supports little more than a
michael@0 124 // peek of the Windows message queue, followed by a dispatch of the peeked
michael@0 125 // message. MessageLoop extends that bare-bones message pump to also service
michael@0 126 // Tasks, at the cost of some complexity.
michael@0 127 //
michael@0 128 // The basic structure of the extension (refered to as a sub-pump) is that a
michael@0 129 // special message, kMsgHaveWork, is repeatedly injected into the Windows
michael@0 130 // Message queue. Each time the kMsgHaveWork message is peeked, checks are
michael@0 131 // made for an extended set of events, including the availability of Tasks to
michael@0 132 // run.
michael@0 133 //
michael@0 134 // After running a task, the special message kMsgHaveWork is again posted to
michael@0 135 // the Windows Message queue, ensuring a future time slice for processing a
michael@0 136 // future event. To prevent flooding the Windows Message queue, care is taken
michael@0 137 // to be sure that at most one kMsgHaveWork message is EVER pending in the
michael@0 138 // Window's Message queue.
michael@0 139 //
michael@0 140 // There are a few additional complexities in this system where, when there are
michael@0 141 // no Tasks to run, this otherwise infinite stream of messages which drives the
michael@0 142 // sub-pump is halted. The pump is automatically re-started when Tasks are
michael@0 143 // queued.
michael@0 144 //
michael@0 145 // A second complexity is that the presence of this stream of posted tasks may
michael@0 146 // prevent a bare-bones message pump from ever peeking a WM_PAINT or WM_TIMER.
michael@0 147 // Such paint and timer events always give priority to a posted message, such as
michael@0 148 // kMsgHaveWork messages. As a result, care is taken to do some peeking in
michael@0 149 // between the posting of each kMsgHaveWork message (i.e., after kMsgHaveWork
michael@0 150 // is peeked, and before a replacement kMsgHaveWork is posted).
michael@0 151 //
michael@0 152 // NOTE: Although it may seem odd that messages are used to start and stop this
michael@0 153 // flow (as opposed to signaling objects, etc.), it should be understood that
michael@0 154 // the native message pump will *only* respond to messages. As a result, it is
michael@0 155 // an excellent choice. It is also helpful that the starter messages that are
michael@0 156 // placed in the queue when new task arrive also awakens DoRunLoop.
michael@0 157 //
michael@0 158 class MessagePumpForUI : public MessagePumpWin {
michael@0 159 public:
michael@0 160 MessagePumpForUI();
michael@0 161 virtual ~MessagePumpForUI();
michael@0 162
michael@0 163 // MessagePump methods:
michael@0 164 virtual void ScheduleWork();
michael@0 165 virtual void ScheduleDelayedWork(const TimeTicks& delayed_work_time);
michael@0 166
michael@0 167 // Applications can call this to encourage us to process all pending WM_PAINT
michael@0 168 // messages. This method will process all paint messages the Windows Message
michael@0 169 // queue can provide, up to some fixed number (to avoid any infinite loops).
michael@0 170 void PumpOutPendingPaintMessages();
michael@0 171
michael@0 172 private:
michael@0 173 static LRESULT CALLBACK WndProcThunk(
michael@0 174 HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam);
michael@0 175 virtual void DoRunLoop();
michael@0 176 void InitMessageWnd();
michael@0 177 void WaitForWork();
michael@0 178 void HandleWorkMessage();
michael@0 179 void HandleTimerMessage();
michael@0 180 bool ProcessNextWindowsMessage();
michael@0 181 bool ProcessMessageHelper(const MSG& msg);
michael@0 182 bool ProcessPumpReplacementMessage();
michael@0 183
michael@0 184 // A hidden message-only window.
michael@0 185 HWND message_hwnd_;
michael@0 186 };
michael@0 187
michael@0 188 //-----------------------------------------------------------------------------
michael@0 189 // MessagePumpForIO extends MessagePumpWin with methods that are particular to a
michael@0 190 // MessageLoop instantiated with TYPE_IO. This version of MessagePump does not
michael@0 191 // deal with Windows mesagges, and instead has a Run loop based on Completion
michael@0 192 // Ports so it is better suited for IO operations.
michael@0 193 //
michael@0 194 class MessagePumpForIO : public MessagePumpWin {
michael@0 195 public:
michael@0 196 struct IOContext;
michael@0 197
michael@0 198 // Clients interested in receiving OS notifications when asynchronous IO
michael@0 199 // operations complete should implement this interface and register themselves
michael@0 200 // with the message pump.
michael@0 201 //
michael@0 202 // Typical use #1:
michael@0 203 // // Use only when there are no user's buffers involved on the actual IO,
michael@0 204 // // so that all the cleanup can be done by the message pump.
michael@0 205 // class MyFile : public IOHandler {
michael@0 206 // MyFile() {
michael@0 207 // ...
michael@0 208 // context_ = new IOContext;
michael@0 209 // context_->handler = this;
michael@0 210 // message_pump->RegisterIOHandler(file_, this);
michael@0 211 // }
michael@0 212 // ~MyFile() {
michael@0 213 // if (pending_) {
michael@0 214 // // By setting the handler to NULL, we're asking for this context
michael@0 215 // // to be deleted when received, without calling back to us.
michael@0 216 // context_->handler = NULL;
michael@0 217 // } else {
michael@0 218 // delete context_;
michael@0 219 // }
michael@0 220 // }
michael@0 221 // virtual void OnIOCompleted(IOContext* context, DWORD bytes_transfered,
michael@0 222 // DWORD error) {
michael@0 223 // pending_ = false;
michael@0 224 // }
michael@0 225 // void DoSomeIo() {
michael@0 226 // ...
michael@0 227 // // The only buffer required for this operation is the overlapped
michael@0 228 // // structure.
michael@0 229 // ConnectNamedPipe(file_, &context_->overlapped);
michael@0 230 // pending_ = true;
michael@0 231 // }
michael@0 232 // bool pending_;
michael@0 233 // IOContext* context_;
michael@0 234 // HANDLE file_;
michael@0 235 // };
michael@0 236 //
michael@0 237 // Typical use #2:
michael@0 238 // class MyFile : public IOHandler {
michael@0 239 // MyFile() {
michael@0 240 // ...
michael@0 241 // message_pump->RegisterIOHandler(file_, this);
michael@0 242 // }
michael@0 243 // // Plus some code to make sure that this destructor is not called
michael@0 244 // // while there are pending IO operations.
michael@0 245 // ~MyFile() {
michael@0 246 // }
michael@0 247 // virtual void OnIOCompleted(IOContext* context, DWORD bytes_transfered,
michael@0 248 // DWORD error) {
michael@0 249 // ...
michael@0 250 // delete context;
michael@0 251 // }
michael@0 252 // void DoSomeIo() {
michael@0 253 // ...
michael@0 254 // IOContext* context = new IOContext;
michael@0 255 // // This is not used for anything. It just prevents the context from
michael@0 256 // // being considered "abandoned".
michael@0 257 // context->handler = this;
michael@0 258 // ReadFile(file_, buffer, num_bytes, &read, &context->overlapped);
michael@0 259 // }
michael@0 260 // HANDLE file_;
michael@0 261 // };
michael@0 262 //
michael@0 263 // Typical use #3:
michael@0 264 // Same as the previous example, except that in order to deal with the
michael@0 265 // requirement stated for the destructor, the class calls WaitForIOCompletion
michael@0 266 // from the destructor to block until all IO finishes.
michael@0 267 // ~MyFile() {
michael@0 268 // while(pending_)
michael@0 269 // message_pump->WaitForIOCompletion(INFINITE, this);
michael@0 270 // }
michael@0 271 //
michael@0 272 class IOHandler {
michael@0 273 public:
michael@0 274 virtual ~IOHandler() {}
michael@0 275 // This will be called once the pending IO operation associated with
michael@0 276 // |context| completes. |error| is the Win32 error code of the IO operation
michael@0 277 // (ERROR_SUCCESS if there was no error). |bytes_transfered| will be zero
michael@0 278 // on error.
michael@0 279 virtual void OnIOCompleted(IOContext* context, DWORD bytes_transfered,
michael@0 280 DWORD error) = 0;
michael@0 281 };
michael@0 282
michael@0 283 // The extended context that should be used as the base structure on every
michael@0 284 // overlapped IO operation. |handler| must be set to the registered IOHandler
michael@0 285 // for the given file when the operation is started, and it can be set to NULL
michael@0 286 // before the operation completes to indicate that the handler should not be
michael@0 287 // called anymore, and instead, the IOContext should be deleted when the OS
michael@0 288 // notifies the completion of this operation. Please remember that any buffers
michael@0 289 // involved with an IO operation should be around until the callback is
michael@0 290 // received, so this technique can only be used for IO that do not involve
michael@0 291 // additional buffers (other than the overlapped structure itself).
michael@0 292 struct IOContext {
michael@0 293 OVERLAPPED overlapped;
michael@0 294 IOHandler* handler;
michael@0 295 };
michael@0 296
michael@0 297 MessagePumpForIO();
michael@0 298 virtual ~MessagePumpForIO() {}
michael@0 299
michael@0 300 // MessagePump methods:
michael@0 301 virtual void ScheduleWork();
michael@0 302 virtual void ScheduleDelayedWork(const TimeTicks& delayed_work_time);
michael@0 303
michael@0 304 // Register the handler to be used when asynchronous IO for the given file
michael@0 305 // completes. The registration persists as long as |file_handle| is valid, so
michael@0 306 // |handler| must be valid as long as there is pending IO for the given file.
michael@0 307 void RegisterIOHandler(HANDLE file_handle, IOHandler* handler);
michael@0 308
michael@0 309 // Waits for the next IO completion that should be processed by |filter|, for
michael@0 310 // up to |timeout| milliseconds. Return true if any IO operation completed,
michael@0 311 // regardless of the involved handler, and false if the timeout expired. If
michael@0 312 // the completion port received any message and the involved IO handler
michael@0 313 // matches |filter|, the callback is called before returning from this code;
michael@0 314 // if the handler is not the one that we are looking for, the callback will
michael@0 315 // be postponed for another time, so reentrancy problems can be avoided.
michael@0 316 // External use of this method should be reserved for the rare case when the
michael@0 317 // caller is willing to allow pausing regular task dispatching on this thread.
michael@0 318 bool WaitForIOCompletion(DWORD timeout, IOHandler* filter);
michael@0 319
michael@0 320 private:
michael@0 321 struct IOItem {
michael@0 322 IOHandler* handler;
michael@0 323 IOContext* context;
michael@0 324 DWORD bytes_transfered;
michael@0 325 DWORD error;
michael@0 326 };
michael@0 327
michael@0 328 virtual void DoRunLoop();
michael@0 329 void WaitForWork();
michael@0 330 bool MatchCompletedIOItem(IOHandler* filter, IOItem* item);
michael@0 331 bool GetIOItem(DWORD timeout, IOItem* item);
michael@0 332 bool ProcessInternalIOItem(const IOItem& item);
michael@0 333
michael@0 334 // The completion port associated with this thread.
michael@0 335 ScopedHandle port_;
michael@0 336 // This list will be empty almost always. It stores IO completions that have
michael@0 337 // not been delivered yet because somebody was doing cleanup.
michael@0 338 std::list<IOItem> completed_io_;
michael@0 339 };
michael@0 340
michael@0 341 } // namespace base
michael@0 342
michael@0 343 #endif // BASE_MESSAGE_PUMP_WIN_H_

mercurial