summaryrefslogtreecommitdiffstats
path: root/chrome/browser/chrome_thread.cc
Commit message (Collapse)AuthorAgeFilesLines
* Fixes bad URLRequest leak detection. nss_ocsp creates asky@chromium.org2010-09-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | URLRequest. This URLRequest, if valid, is deleted when the IO thread is being shutdown by way of a DestructionObserver attached to the IO thread. Prior to this patch this proves problematic as the LeakTracker is run before DestructionObservers, which means we were errorenously detecting a leak and causing random UI failures (and perhaps other tests). To fix this I've moved the LeakTracker to run after the IO thread MessageLoop has been deleted (which means DestructionObservers have been notified). Doing this triggered a DCHECK in ChromeNetLog::AddEntry: DCHECK(ChromeThread::CurrentlyOn(ChromeThread::IO)); Here's the full stack: StackTrace::StackTrace() [0xf247c1] logging::LogMessage::~LogMessage() [0xf3ef4f] ChromeNetLog::AddEntry() [0x5c9639] net::BoundNetLog::AddEntry() [0x147d8a3] net::BoundNetLog::AddEvent() [0x147d92a] net::internal::ClientSocketPoolBaseHelper::CancelRequest() [0x132d032] net::ClientSocketPoolBase<>::CancelRequest() [0x134aabd] net::TCPClientSocketPool::CancelRequest() [0x1348fdb] net::ClientSocketHandle::ResetInternal() [0x13273b7] net::ClientSocketHandle::Reset() [0x1327874] net::ClientSocketHandle::~ClientSocketHandle() [0x1327895] scoped_ptr<>::~scoped_ptr() [0x1304b97] net::HttpStreamRequest::~HttpStreamRequest() [0x1300933] base::RefCounted<>::Release() [0xa15b83] scoped_refptr<>::operator=() [0x12f2da4] net::HttpNetworkTransaction::~HttpNetworkTransaction() [0x12ee377] scoped_ptr<>::~scoped_ptr() [0x12e2724] net::HttpCache::Transaction::~Transaction() [0x12e10a6] scoped_ptr<>::reset() [0x12d1f0b] URLRequestHttpJob::DestroyTransaction() [0x142229e] URLRequestHttpJob::Kill() [0x14252e5] URLRequest::DoCancel() [0x137af1e] URLRequest::Cancel() [0x137b081] (anonymous namespace)::OCSPRequestSession::CancelURLRequest() [0x13142a7] (anonymous namespace)::OCSPRequestSession::WillDestroyCurrentMessageLoop() [0x1314b30] MessageLoop::~MessageLoop() [0xf421ab] base::Thread::ThreadMain() [0xf71395] ThreadFunc() [0xf54338] start_thread [0x7ff66c6d83f7] 0x7ff669d5cbbd This is still on the IO thread, but the DCHECK fails because at the time the DestructionObservers are run Thread::message_loop() returns NULL, which means the DCHECK fails. I've fixed this by changing the DCHECK to pass if the current thread's message loop is NULL. I feel a bit quesy about this as it seems a bit fragile (well, all this code is fragile). I would be inclined to make Thread::message_loop() return the MessageLoop until after the destructor has run, but this seems equally risky. Let me know what you prefer. BUG=52022 TEST=none Review URL: http://codereview.chromium.org/3402006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59566 0039d316-1c4b-4281-b951-d872f2087c98
* Create a dedicated cache thread and use it to create thervargas@google.com2010-05-181-0/+1
| | | | | | | | | | | Http cache. BUG=26730 TEST=none Review URL: http://codereview.chromium.org/1989014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47564 0039d316-1c4b-4281-b951-d872f2087c98
* Created a stock implementation of the MessageLoopProxy interface than can be ↵sanjeevr@chromium.org2010-05-061-3/+4
| | | | | | | | | | | used to create an implementation that targets the current thread's message loop. BUG=None TEST=Unit tests provided. Review URL: http://codereview.chromium.org/1837003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46591 0039d316-1c4b-4281-b951-d872f2087c98
* Changed UrlFetcher to use a MessageLoopProxy instead of directly relying on ↵sanjeevr@chromium.org2010-05-031-0/+3
| | | | | | | | | | | ChromeThread. This will allow us to make UrlFetcher independent of ChromeThread and we can then move it to chrome/common. BUG=None TEST=UrlFetcher unit-tests Review URL: http://codereview.chromium.org/1702016 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46282 0039d316-1c4b-4281-b951-d872f2087c98
* Created a MessageLoopProxy interface. This provides a thread-safe refcounted ↵sanjeevr@chromium.org2010-04-291-0/+47
| | | | | | | | | | | | interface to the Post* methods of a message loop. This class can outlive the target message loop. Changed ChromeThread to vend an implementation of this proxy. BUG=None TEST=ChromeThread unit-tests modified. Review URL: http://codereview.chromium.org/1800008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45907 0039d316-1c4b-4281-b951-d872f2087c98
* Cleanup: Explicitly add a bunch of missing includes.thestig@chromium.org2010-04-151-1/+3
| | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/1623014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44635 0039d316-1c4b-4281-b951-d872f2087c98
* BSD ifdefs, etc. necessary for chrome/pvalchev@google.com2010-03-091-1/+1
| | | | | | Review URL: http://codereview.chromium.org/656009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41067 0039d316-1c4b-4281-b951-d872f2087c98
* Adding instrument to NotificationRegistrar to checkhuanr@chromium.org2009-12-041-0/+7
| | | | | | | | | | | | | | | Add() and Remove() are called from same thread. Note I already checked in a fix for the bug. The CL is trying to check whether the issue exists in other code path. TEST=none BUG=27834 Review URL: http://codereview.chromium.org/449044 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33802 0039d316-1c4b-4281-b951-d872f2087c98
* Fix bug when accessing g_browser_process->broker_services() at shutdown.jam@chromium.org2009-11-231-0/+1
| | | | | | | BUG=28501 Review URL: http://codereview.chromium.org/435001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32832 0039d316-1c4b-4281-b951-d872f2087c98
* Stop each ChromeThread before nulling out the entry in chrome_threads_. ↵jam@chromium.org2009-11-041-0/+5
| | | | | | | | | This allows DCHECKs that the code is running on the correct thread to succeed. BUG=26714 Review URL: http://codereview.chromium.org/363010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31010 0039d316-1c4b-4281-b951-d872f2087c98
* Fifth patch in getting rid of caching MessageLoop pointers.jam@chromium.org2009-11-031-3/+0
| | | | | | | BUG=25354 Review URL: http://codereview.chromium.org/345037 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30790 0039d316-1c4b-4281-b951-d872f2087c98
* Simplify threading in browser thread by making only ChromeThread deal with ↵jam@chromium.org2009-10-271-28/+101
| | | | | | | | different thread lifetimes.The rest of the code doesn't get MessageLoop pointers since they're not thread-safe and instead just call PostTask on ChromeThread. If the target thread is not alive, then the task is simply deleted.In a followup change, I'll remove any remaining MessageLoop* caching. With this change, there's little to be gained by caching since no locks are involved if the target MessageLoop is guaranteed to outlive the current thread (inferred automatically by the order of the chrome_threads_ array).BUG=25354 Review URL: http://codereview.chromium.org/306032 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30163 0039d316-1c4b-4281-b951-d872f2087c98
* Switch history thread back to base::Thread. Sync unit tests require more ↵chron@chromium.org2009-09-211-2/+0
| | | | | | | | | | than one history thread. We hope to have a hard unit test dependency on buildbot soon, but we need to fix our tests again now. BUG=22056 Review URL: http://codereview.chromium.org/215023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26709 0039d316-1c4b-4281-b951-d872f2087c98
* Add the UI thread to the list of ChromeThreads.paul@chromium.org2009-08-181-2/+16
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/171088 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23605 0039d316-1c4b-4281-b951-d872f2087c98
* Simplify the WebKit thread model. It's now created/destroyed on the UI ↵jorlow@chromium.org2009-07-081-0/+12
| | | | | | | | thread (before/after the IO thread is started/stopped). The WebKit thread is created lazily as needed (while on the IO thread).TEST=noneBUG=none Review URL: http://codereview.chromium.org/149238 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20109 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: move X operations from the IO to UI2 thread.agl@chromium.org2009-04-221-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | (r14075 take two) Currently we perform several X operations on the IO thread including geometry and clipboard work. This is causing races inside Xlib and crashing the browser. These are the result of synchronous calls from the renderer, so we cannot route these requests to the UI thread without risking deadlock. Thus we introduce the UI2 thread. This thread has a second connection to the X server and can perform X operations safely the without UI thread. Work remains to be done: Since we still have the hack where we pass GtkWidget pointers into the renderer and back, we still have to access these structures from the IO and UI2 threads. This still needs to be fixed, but this is not the patch for it. Also, not all the X calls from the IO thread have been moved over in this patch; just a few small ones. http://codereview.chromium.org/67145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14206 0039d316-1c4b-4281-b951-d872f2087c98
* I managed to break test_shell. Reverting. I'll fix tomorrow.agl@chromium.org2009-04-211-8/+0
| | | | | | | Reverts r14075 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14080 0039d316-1c4b-4281-b951-d872f2087c98
* Linux: move X operations from the IO to UI2 thread.agl@chromium.org2009-04-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we perform several X operations on the IO thread including geometry and clipboard work. This is causing races inside Xlib and crashing the browser. These are the result of synchronous calls from the renderer, so we cannot route these requests to the UI thread without risking deadlock. Thus we introduce the UI2 thread. This thread has a second connection to the X server and can perform X operations safely the without UI thread. Work remains to be done: Since we still have the hack where we pass GtkWidget pointers into the renderer and back, we still have to access these structures from the IO and UI2 threads. This still needs to be fixed, but this is not the patch for it. Also, not all the X calls from the IO thread have been moved over in this patch; just a few small ones. http://codereview.chromium.org/67145 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14075 0039d316-1c4b-4281-b951-d872f2087c98
* Give each HistoryService instance it's own backend thread.tim@chromium.org2009-04-141-2/+0
| | | | | | | | | | | | | | | | | I had originally planned to push history_thread up to BrowserProcess, but was scared away by the comment in ~Profile that talks about HistoryService calling back into the bookmark bar model, and that it depended on join()ing at that particular time to ensure this doesn't happen after the bookmark bar model has been reset. I didn't use scoped_ptr for the thread because it makes the little dance in CleanUp awkward. TEST=any existing test that exersizes the history service. I added a ProfileManager test that would fail without this change. Review URL: http://codereview.chromium.org/73012 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13703 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGEdeanm@chromium.org2009-03-101-1/+0
| | | | | | | | | Normalize end of file newlines in chrome/. All files end in a single newline. Review URL: http://codereview.chromium.org/42015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11331 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
* Add chrome to the repository.initial.commit2008-07-261-0/+72
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98