1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/ipc/chromium/src/base/message_pump_win.h Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,343 @@
1.4 +// Copyright (c) 2006-2008 The Chromium Authors. All rights reserved.
1.5 +// Use of this source code is governed by a BSD-style license that can be
1.6 +// found in the LICENSE file.
1.7 +
1.8 +#ifndef BASE_MESSAGE_PUMP_WIN_H_
1.9 +#define BASE_MESSAGE_PUMP_WIN_H_
1.10 +
1.11 +#include <windows.h>
1.12 +
1.13 +#include <list>
1.14 +
1.15 +#include "base/lock.h"
1.16 +#include "base/message_pump.h"
1.17 +#include "base/observer_list.h"
1.18 +#include "base/scoped_handle.h"
1.19 +#include "base/time.h"
1.20 +
1.21 +namespace base {
1.22 +
1.23 +// MessagePumpWin serves as the base for specialized versions of the MessagePump
1.24 +// for Windows. It provides basic functionality like handling of observers and
1.25 +// controlling the lifetime of the message pump.
1.26 +class MessagePumpWin : public MessagePump {
1.27 + public:
1.28 + // An Observer is an object that receives global notifications from the
1.29 + // MessageLoop.
1.30 + //
1.31 + // NOTE: An Observer implementation should be extremely fast!
1.32 + //
1.33 + class Observer {
1.34 + public:
1.35 + virtual ~Observer() {}
1.36 +
1.37 + // This method is called before processing a message.
1.38 + // The message may be undefined in which case msg.message is 0
1.39 + virtual void WillProcessMessage(const MSG& msg) = 0;
1.40 +
1.41 + // This method is called when control returns from processing a UI message.
1.42 + // The message may be undefined in which case msg.message is 0
1.43 + virtual void DidProcessMessage(const MSG& msg) = 0;
1.44 + };
1.45 +
1.46 + // Dispatcher is used during a nested invocation of Run to dispatch events.
1.47 + // If Run is invoked with a non-NULL Dispatcher, MessageLoop does not
1.48 + // dispatch events (or invoke TranslateMessage), rather every message is
1.49 + // passed to Dispatcher's Dispatch method for dispatch. It is up to the
1.50 + // Dispatcher to dispatch, or not, the event.
1.51 + //
1.52 + // The nested loop is exited by either posting a quit, or returning false
1.53 + // from Dispatch.
1.54 + class Dispatcher {
1.55 + public:
1.56 + virtual ~Dispatcher() {}
1.57 + // Dispatches the event. If true is returned processing continues as
1.58 + // normal. If false is returned, the nested loop exits immediately.
1.59 + virtual bool Dispatch(const MSG& msg) = 0;
1.60 + };
1.61 +
1.62 + MessagePumpWin() : have_work_(0), state_(NULL) {}
1.63 + virtual ~MessagePumpWin() {}
1.64 +
1.65 + // Add an Observer, which will start receiving notifications immediately.
1.66 + void AddObserver(Observer* observer);
1.67 +
1.68 + // Remove an Observer. It is safe to call this method while an Observer is
1.69 + // receiving a notification callback.
1.70 + void RemoveObserver(Observer* observer);
1.71 +
1.72 + // Give a chance to code processing additional messages to notify the
1.73 + // message loop observers that another message has been processed.
1.74 + void WillProcessMessage(const MSG& msg);
1.75 + void DidProcessMessage(const MSG& msg);
1.76 +
1.77 + // Like MessagePump::Run, but MSG objects are routed through dispatcher.
1.78 + void RunWithDispatcher(Delegate* delegate, Dispatcher* dispatcher);
1.79 +
1.80 + // MessagePump methods:
1.81 + virtual void Run(Delegate* delegate) { RunWithDispatcher(delegate, NULL); }
1.82 + virtual void Quit();
1.83 +
1.84 + protected:
1.85 + struct RunState {
1.86 + Delegate* delegate;
1.87 + Dispatcher* dispatcher;
1.88 +
1.89 + // Used to flag that the current Run() invocation should return ASAP.
1.90 + bool should_quit;
1.91 +
1.92 + // Used to count how many Run() invocations are on the stack.
1.93 + int run_depth;
1.94 + };
1.95 +
1.96 + virtual void DoRunLoop() = 0;
1.97 + int GetCurrentDelay() const;
1.98 +
1.99 + ObserverList<Observer> observers_;
1.100 +
1.101 + // The time at which delayed work should run.
1.102 + TimeTicks delayed_work_time_;
1.103 +
1.104 + // A boolean value used to indicate if there is a kMsgDoWork message pending
1.105 + // in the Windows Message queue. There is at most one such message, and it
1.106 + // can drive execution of tasks when a native message pump is running.
1.107 + LONG have_work_;
1.108 +
1.109 + // State for the current invocation of Run.
1.110 + RunState* state_;
1.111 +};
1.112 +
1.113 +//-----------------------------------------------------------------------------
1.114 +// MessagePumpForUI extends MessagePumpWin with methods that are particular to a
1.115 +// MessageLoop instantiated with TYPE_UI.
1.116 +//
1.117 +// MessagePumpForUI implements a "traditional" Windows message pump. It contains
1.118 +// a nearly infinite loop that peeks out messages, and then dispatches them.
1.119 +// Intermixed with those peeks are callouts to DoWork for pending tasks, and
1.120 +// DoDelayedWork for pending timers. When there are no events to be serviced,
1.121 +// this pump goes into a wait state. In most cases, this message pump handles
1.122 +// all processing.
1.123 +//
1.124 +// However, when a task, or windows event, invokes on the stack a native dialog
1.125 +// box or such, that window typically provides a bare bones (native?) message
1.126 +// pump. That bare-bones message pump generally supports little more than a
1.127 +// peek of the Windows message queue, followed by a dispatch of the peeked
1.128 +// message. MessageLoop extends that bare-bones message pump to also service
1.129 +// Tasks, at the cost of some complexity.
1.130 +//
1.131 +// The basic structure of the extension (refered to as a sub-pump) is that a
1.132 +// special message, kMsgHaveWork, is repeatedly injected into the Windows
1.133 +// Message queue. Each time the kMsgHaveWork message is peeked, checks are
1.134 +// made for an extended set of events, including the availability of Tasks to
1.135 +// run.
1.136 +//
1.137 +// After running a task, the special message kMsgHaveWork is again posted to
1.138 +// the Windows Message queue, ensuring a future time slice for processing a
1.139 +// future event. To prevent flooding the Windows Message queue, care is taken
1.140 +// to be sure that at most one kMsgHaveWork message is EVER pending in the
1.141 +// Window's Message queue.
1.142 +//
1.143 +// There are a few additional complexities in this system where, when there are
1.144 +// no Tasks to run, this otherwise infinite stream of messages which drives the
1.145 +// sub-pump is halted. The pump is automatically re-started when Tasks are
1.146 +// queued.
1.147 +//
1.148 +// A second complexity is that the presence of this stream of posted tasks may
1.149 +// prevent a bare-bones message pump from ever peeking a WM_PAINT or WM_TIMER.
1.150 +// Such paint and timer events always give priority to a posted message, such as
1.151 +// kMsgHaveWork messages. As a result, care is taken to do some peeking in
1.152 +// between the posting of each kMsgHaveWork message (i.e., after kMsgHaveWork
1.153 +// is peeked, and before a replacement kMsgHaveWork is posted).
1.154 +//
1.155 +// NOTE: Although it may seem odd that messages are used to start and stop this
1.156 +// flow (as opposed to signaling objects, etc.), it should be understood that
1.157 +// the native message pump will *only* respond to messages. As a result, it is
1.158 +// an excellent choice. It is also helpful that the starter messages that are
1.159 +// placed in the queue when new task arrive also awakens DoRunLoop.
1.160 +//
1.161 +class MessagePumpForUI : public MessagePumpWin {
1.162 + public:
1.163 + MessagePumpForUI();
1.164 + virtual ~MessagePumpForUI();
1.165 +
1.166 + // MessagePump methods:
1.167 + virtual void ScheduleWork();
1.168 + virtual void ScheduleDelayedWork(const TimeTicks& delayed_work_time);
1.169 +
1.170 + // Applications can call this to encourage us to process all pending WM_PAINT
1.171 + // messages. This method will process all paint messages the Windows Message
1.172 + // queue can provide, up to some fixed number (to avoid any infinite loops).
1.173 + void PumpOutPendingPaintMessages();
1.174 +
1.175 + private:
1.176 + static LRESULT CALLBACK WndProcThunk(
1.177 + HWND hwnd, UINT message, WPARAM wparam, LPARAM lparam);
1.178 + virtual void DoRunLoop();
1.179 + void InitMessageWnd();
1.180 + void WaitForWork();
1.181 + void HandleWorkMessage();
1.182 + void HandleTimerMessage();
1.183 + bool ProcessNextWindowsMessage();
1.184 + bool ProcessMessageHelper(const MSG& msg);
1.185 + bool ProcessPumpReplacementMessage();
1.186 +
1.187 + // A hidden message-only window.
1.188 + HWND message_hwnd_;
1.189 +};
1.190 +
1.191 +//-----------------------------------------------------------------------------
1.192 +// MessagePumpForIO extends MessagePumpWin with methods that are particular to a
1.193 +// MessageLoop instantiated with TYPE_IO. This version of MessagePump does not
1.194 +// deal with Windows mesagges, and instead has a Run loop based on Completion
1.195 +// Ports so it is better suited for IO operations.
1.196 +//
1.197 +class MessagePumpForIO : public MessagePumpWin {
1.198 + public:
1.199 + struct IOContext;
1.200 +
1.201 + // Clients interested in receiving OS notifications when asynchronous IO
1.202 + // operations complete should implement this interface and register themselves
1.203 + // with the message pump.
1.204 + //
1.205 + // Typical use #1:
1.206 + // // Use only when there are no user's buffers involved on the actual IO,
1.207 + // // so that all the cleanup can be done by the message pump.
1.208 + // class MyFile : public IOHandler {
1.209 + // MyFile() {
1.210 + // ...
1.211 + // context_ = new IOContext;
1.212 + // context_->handler = this;
1.213 + // message_pump->RegisterIOHandler(file_, this);
1.214 + // }
1.215 + // ~MyFile() {
1.216 + // if (pending_) {
1.217 + // // By setting the handler to NULL, we're asking for this context
1.218 + // // to be deleted when received, without calling back to us.
1.219 + // context_->handler = NULL;
1.220 + // } else {
1.221 + // delete context_;
1.222 + // }
1.223 + // }
1.224 + // virtual void OnIOCompleted(IOContext* context, DWORD bytes_transfered,
1.225 + // DWORD error) {
1.226 + // pending_ = false;
1.227 + // }
1.228 + // void DoSomeIo() {
1.229 + // ...
1.230 + // // The only buffer required for this operation is the overlapped
1.231 + // // structure.
1.232 + // ConnectNamedPipe(file_, &context_->overlapped);
1.233 + // pending_ = true;
1.234 + // }
1.235 + // bool pending_;
1.236 + // IOContext* context_;
1.237 + // HANDLE file_;
1.238 + // };
1.239 + //
1.240 + // Typical use #2:
1.241 + // class MyFile : public IOHandler {
1.242 + // MyFile() {
1.243 + // ...
1.244 + // message_pump->RegisterIOHandler(file_, this);
1.245 + // }
1.246 + // // Plus some code to make sure that this destructor is not called
1.247 + // // while there are pending IO operations.
1.248 + // ~MyFile() {
1.249 + // }
1.250 + // virtual void OnIOCompleted(IOContext* context, DWORD bytes_transfered,
1.251 + // DWORD error) {
1.252 + // ...
1.253 + // delete context;
1.254 + // }
1.255 + // void DoSomeIo() {
1.256 + // ...
1.257 + // IOContext* context = new IOContext;
1.258 + // // This is not used for anything. It just prevents the context from
1.259 + // // being considered "abandoned".
1.260 + // context->handler = this;
1.261 + // ReadFile(file_, buffer, num_bytes, &read, &context->overlapped);
1.262 + // }
1.263 + // HANDLE file_;
1.264 + // };
1.265 + //
1.266 + // Typical use #3:
1.267 + // Same as the previous example, except that in order to deal with the
1.268 + // requirement stated for the destructor, the class calls WaitForIOCompletion
1.269 + // from the destructor to block until all IO finishes.
1.270 + // ~MyFile() {
1.271 + // while(pending_)
1.272 + // message_pump->WaitForIOCompletion(INFINITE, this);
1.273 + // }
1.274 + //
1.275 + class IOHandler {
1.276 + public:
1.277 + virtual ~IOHandler() {}
1.278 + // This will be called once the pending IO operation associated with
1.279 + // |context| completes. |error| is the Win32 error code of the IO operation
1.280 + // (ERROR_SUCCESS if there was no error). |bytes_transfered| will be zero
1.281 + // on error.
1.282 + virtual void OnIOCompleted(IOContext* context, DWORD bytes_transfered,
1.283 + DWORD error) = 0;
1.284 + };
1.285 +
1.286 + // The extended context that should be used as the base structure on every
1.287 + // overlapped IO operation. |handler| must be set to the registered IOHandler
1.288 + // for the given file when the operation is started, and it can be set to NULL
1.289 + // before the operation completes to indicate that the handler should not be
1.290 + // called anymore, and instead, the IOContext should be deleted when the OS
1.291 + // notifies the completion of this operation. Please remember that any buffers
1.292 + // involved with an IO operation should be around until the callback is
1.293 + // received, so this technique can only be used for IO that do not involve
1.294 + // additional buffers (other than the overlapped structure itself).
1.295 + struct IOContext {
1.296 + OVERLAPPED overlapped;
1.297 + IOHandler* handler;
1.298 + };
1.299 +
1.300 + MessagePumpForIO();
1.301 + virtual ~MessagePumpForIO() {}
1.302 +
1.303 + // MessagePump methods:
1.304 + virtual void ScheduleWork();
1.305 + virtual void ScheduleDelayedWork(const TimeTicks& delayed_work_time);
1.306 +
1.307 + // Register the handler to be used when asynchronous IO for the given file
1.308 + // completes. The registration persists as long as |file_handle| is valid, so
1.309 + // |handler| must be valid as long as there is pending IO for the given file.
1.310 + void RegisterIOHandler(HANDLE file_handle, IOHandler* handler);
1.311 +
1.312 + // Waits for the next IO completion that should be processed by |filter|, for
1.313 + // up to |timeout| milliseconds. Return true if any IO operation completed,
1.314 + // regardless of the involved handler, and false if the timeout expired. If
1.315 + // the completion port received any message and the involved IO handler
1.316 + // matches |filter|, the callback is called before returning from this code;
1.317 + // if the handler is not the one that we are looking for, the callback will
1.318 + // be postponed for another time, so reentrancy problems can be avoided.
1.319 + // External use of this method should be reserved for the rare case when the
1.320 + // caller is willing to allow pausing regular task dispatching on this thread.
1.321 + bool WaitForIOCompletion(DWORD timeout, IOHandler* filter);
1.322 +
1.323 + private:
1.324 + struct IOItem {
1.325 + IOHandler* handler;
1.326 + IOContext* context;
1.327 + DWORD bytes_transfered;
1.328 + DWORD error;
1.329 + };
1.330 +
1.331 + virtual void DoRunLoop();
1.332 + void WaitForWork();
1.333 + bool MatchCompletedIOItem(IOHandler* filter, IOItem* item);
1.334 + bool GetIOItem(DWORD timeout, IOItem* item);
1.335 + bool ProcessInternalIOItem(const IOItem& item);
1.336 +
1.337 + // The completion port associated with this thread.
1.338 + ScopedHandle port_;
1.339 + // This list will be empty almost always. It stores IO completions that have
1.340 + // not been delivered yet because somebody was doing cleanup.
1.341 + std::list<IOItem> completed_io_;
1.342 +};
1.343 +
1.344 +} // namespace base
1.345 +
1.346 +#endif // BASE_MESSAGE_PUMP_WIN_H_
