summaryrefslogtreecommitdiffstats
path: root/base/message_pump_win.cc
Commit message (Collapse)AuthorAgeFilesLines
* Relanding this. jcampan@chromium.org2009-04-271-1/+2
| | | | | | | | | | | | | | | | | | | The Ole unitialization was failing on one of the Vista build-bot. It is not clear when the Ole initialization is balanced when a CRichEditCtrl is created/destructed. So I now turn it off explicitly. This CL makes sure we unregister our Windows window classes when shut-down. It also balances-out an OLE initialization performed by the CRichEditCTRL. This is necessary for allowing to reload chrome.dll in a process, which is what the browser tests will do. BUG=None TEST=None Review URL: http://codereview.chromium.org/101004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14649 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting 14489.jcampan@chromium.org2009-04-241-1/+0
| | | | | | Review URL: http://codereview.chromium.org/99004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14492 0039d316-1c4b-4281-b951-d872f2087c98
* This CL makes sure we unregister our Windows window classes when shut-down.jcampan@chromium.org2009-04-241-0/+1
| | | | | | | | | | | | It also balances-out an OLE initialization performed by the CRichEditCTRL. This is necessary for allowing to reload chrome.dll in a process, which is what the browser tests will do. BUG=None TEST=None Review URL: http://codereview.chromium.org/93026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14489 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGE (except one global std::wstring changed to const wchar_t* ↵maruel@chromium.org2009-03-031-1/+1
| | | | | | | | | | | const per style compliance). Preliminary work to enforce new PRESUBMIT.py rules: - <=80 cols - no trailing whitespaces - svn:eol-style=LF git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10791 0039d316-1c4b-4281-b951-d872f2087c98
* Use string for Histogram names since these are all ASCII anyway.dsh@google.com2009-02-241-1/+1
| | | | | | | | Wide-character literals cause problems between platforms. Review URL: http://codereview.chromium.org/28046 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10276 0039d316-1c4b-4281-b951-d872f2087c98
* Re-land rollback (which was not causing UI test regression)jar@google.com2008-12-131-5/+11
| | | | | | tbr=ojan git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6963 0039d316-1c4b-4281-b951-d872f2087c98
* Revert to repair UI test bustagejar@google.com2008-12-121-11/+5
| | | | | | | tbr=darin Review URL: http://codereview.chromium.org/14069 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6917 0039d316-1c4b-4281-b951-d872f2087c98
* Make sure sub-pump is running (if needed) before handling a windows taskjar@google.com2008-12-121-5/+11
| | | | | | | | | | | | I still need to performance test this, and carefully check all paths, but I think this is a reasonable shot at the fix. bug=4808 r=darin Review URL: http://codereview.chromium.org/13733 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6898 0039d316-1c4b-4281-b951-d872f2087c98
* Switch MessagePumpForIO to use completion ports on Windows.rvargas@google.com2008-11-071-407/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cleanup the separation between MessagePumpForUI and MessagePumpForIO, and convert the latter to use Completion Ports instead of MsgWaitForMultipleobjects to sleep when idle. Remove all traces of Windows messages from MessagePumpForIO, remove the transitional API of completion port notifications and remove WatchObject API. Modify all callers of RegisterIOHandler so that they are no longer using RegisterIOContext, and also handle properly the new semantics of completion ports (notifications even when the IO completes immediately). Add a new interface to allow proper cleanup of disk cache (to replace code that was waiting for pending APCs from the destructor). Add a way for the message pump to perform cleanup of abandoned IO. BUG=B/1344358, 3497, 3630 TESt=unit tests R=darin Review URL: http://codereview.chromium.org/8156 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5021 0039d316-1c4b-4281-b951-d872f2087c98
* Move Time, TimeDelta and TimeTicks into namespace base.dsh@google.com2008-10-271-0/+2
| | | | | | Review URL: http://codereview.chromium.org/7995 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4022 0039d316-1c4b-4281-b951-d872f2087c98
* Add a way to register for completion-ports based async operations to be handledrvargas@google.com2008-10-091-0/+69
| | | | | | | | | | | through the windows version of the message pump. As a first step, actual IO processing is still performed using WatchObject instead of using completion ports. Review URL: http://codereview.chromium.org/1950 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3157 0039d316-1c4b-4281-b951-d872f2087c98
* This fixes http://code.google.com/p/chromium/issues/detail?id=772,iyengar@google.com2008-10-011-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | which was an issue with the browser UI thread entering a tight loop at times. The thread inputs of the browser UI thread and the plugin thread are attached due to the parent child relationship between the windows. As a result at times the MsgWaitForMultipleObjectsEx API returns the fact that there are messages in the queue (mouse messages). The subsequent peek fails to return any messages causing us to enter a loop for a while. This also happens when the plugin has capture and just before it releases capture, some mousemoves end up in the browser ui thread causing a tight loop. The fix is to check if there are mouse messages in the queue by invoking GetQueueStatus and attempting to peek them out with PM_NOREMOVE. If this fails we call WaitMessage to block until the next message. The other fix is to return true from ProcessNextWindowsMessage if PeekMessage returns false and there were sent messages in the queue, as this is as expected. This will ensure that we go back up and peek again instead of calling MsgWaitForMultipleObjectsEx again. Bug=772 R=darin Review URL: http://codereview.chromium.org/6021 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2740 0039d316-1c4b-4281-b951-d872f2087c98
* As an intermediate step towards having a message pump handling IO through ↵rvargas@google.com2008-09-251-117/+197
| | | | | | | | | | completion ports, this CL creates two types of message pumps for windows: one to handle UI threads and another one to handle IO threads. I'm basically moving stuff around, except by the fact that now UI threads will not process APCs or wait on objects (those things only happen on message loops of TYPE_IO) Review URL: http://codereview.chromium.org/3094 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2602 0039d316-1c4b-4281-b951-d872f2087c98
* Fix crash that can occur if PumpOutPendingPaintMessages is called outside ↵darin@chromium.org2008-09-191-0/+5
| | | | | | | | | | the context of MessagePump::Run. R=jar Review URL: http://codereview.chromium.org/3137 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2415 0039d316-1c4b-4281-b951-d872f2087c98
* A better fix for the hang observed while running net_unittests on vista. Thisdarin@google.com2008-08-301-8/+10
| | | | | | | | | | | fix avoids a crash as well by not calling ProcessPumpReplacementMessage. Instead, we just reset the have_work_ flag. TBR=rvargas,jar BUG=1351146 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1580 0039d316-1c4b-4281-b951-d872f2087c98
* Switch SharedTimerWin over to using PostDelayedTask. I made some tweaks to thedarin@google.com2008-08-301-4/+1
| | | | | | | | | | | | | PostDelayedTask implementation to ensure that perf is still good. This involved recording the intended fire time of PostDelayedTask on the Task object so that it can be used to properly determine the delay passed to the StartTimer call. With this change, I am able to service timers (call DoDelayedWork) more often from within the MessagePump implementations. R=mbelshe BUG=1346553 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1578 0039d316-1c4b-4281-b951-d872f2087c98
* Fix net_unittests hang observed on Vista. It turns out that a subpump wasdarin@google.com2008-08-291-5/+6
| | | | | | | | | | | | | | | | | being run within shell32, which was causing our kHaveWorkMsg to get dispatched. However, because that was occuring outside the context of a MessagePump::Run call, the handler for kHaveWorkMsg was returning early. Unfortunately, this means that it was failing to reset the have_work_ sentinel to 0. Because of that future calls to ScheduleWork would always be a no-op (as they return early when have_work_ is already set to 1). The proper fix is to just re-order the calls so that ProcessPumpReplacementMessage always runs in response to kHaveWorkMsg, but we still suppress calling DoWork until we are inside MessagePump::Run. TBR=rvargas,jar git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1544 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* reland r1075 w/ tweak to fix test failuresdarin@google.com2008-08-201-12/+25
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1084 0039d316-1c4b-4281-b951-d872f2087c98
* rollback r1075 to see if it helps resolve test failuresdarin@google.com2008-08-201-25/+12
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1078 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate TimerManager::GetCurrentDelay in favor of always referring to the ↵darin@google.com2008-08-201-12/+25
| | | | | | | | | | | fire time of the next timer. I changed the MessagePump API to refer to a delayed_work_time instead of a delay. I moved the ceil-based rounding code into the Window's implementations of WaitableEvent and MessagePump. R=jar git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1075 0039d316-1c4b-4281-b951-d872f2087c98
* Take 2 at the new MessageLoop implementation.darin@google.com2008-08-161-2/+14
| | | | | | | | R=jar git-svn-id: svn://svn.chromium.org/chrome/trunk/src@973 0039d316-1c4b-4281-b951-d872f2087c98
* Just like HandleWorkMessage, we have to be concerned with HandleTimerMessagedarin@google.com2008-08-151-0/+6
| | | | | | | | | | | being called outside the context of our Run method. In such cases, just kill the timer, and return. This fixes the crash that was observed with the Firefox3 importer unit test on Vista. TBR=jar git-svn-id: svn://svn.chromium.org/chrome/trunk/src@933 0039d316-1c4b-4281-b951-d872f2087c98
* Try only re-scheduling work when HandleWorkMessage is called.darin@google.com2008-08-151-1/+2
| | | | | | | TBR=jar git-svn-id: svn://svn.chromium.org/chrome/trunk/src@930 0039d316-1c4b-4281-b951-d872f2087c98
* remove some testing code that i didn't mean to checkindarin@google.com2008-08-151-16/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@929 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce MessagePump to represent the native message pump used to drive adarin@google.com2008-08-151-0/+523
MessageLoop. A MessageLoop now has a MessagePump. This will make it possible to port the MessagePump interface to other platforms as well as to use an IO completion port for our worker threads on Windows. Currently, there is only MessagePumpWin, which attempts to preserve the pre-existing behavior of the MessageLoop. API changes to MessageLoop: 1. MessageLoop::Quit means return from Run when the MessageLoop would otherwise wait for more work. 2. MessageLoop::Quit can no longer be called outside the context of an active Run call. So, things like this: MessageLoop::current()->Quit(); MessageLoop::current()->Run(); are now: MessageLoop::current()->RunAllPending(); 3. MessageLoop::Quit can no longer be called from other threads. This means that PostTask(..., new MessageLoop::QuitTask()) must be used explicitly to Quit across thread boundaries. 4. No protection is made to deal with nested MessageLoops involving watched objects or APCs. In fact, an assertion is added to flag such cases. This is a temporary measure until object watching and APC facilities are removed in favor of a MessagePump designed around an IO completion port. As part of this CL, I also changed the automation system to use an IPC::ChannelProxy instead of an IPC::Channel. This moves the automation IPC onto Chrome's IO thread where it belongs. I also fixed some abuses of RefCounted in the AutomationProvider class. It was deleting itself in some cases! This led to having to fix the ownership model for AutomationProvider, which explains the changes to AutomationProviderList and so on. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@928 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-30 19:55:26 +0000