TODO: Fix the remaining usages in third_party libraries and get rid of the macro in question.

BUG=None
TEST=trybots

Review URL: http://codereview.chromium.org/2657005

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49032 0039d316-1c4b-4281-b951-d872f2087c98

client_socket_pool_base.cc change contributed by vandebo@chromium

BUG=42904
TEST=existing net tests/

Review URL: http://codereview.chromium.org/1756019

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46409 0039d316-1c4b-4281-b951-d872f2087c98

cache histograms.

BUG=14193
TEST=none

Review URL: http://codereview.chromium.org/650068

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39654 0039d316-1c4b-4281-b951-d872f2087c98

of any operation that may block.

BUG=26730
TEST=none

Review URL: http://codereview.chromium.org/355028

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31160 0039d316-1c4b-4281-b951-d872f2087c98

BUG=24444

Review URL: http://codereview.chromium.org/270066

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28742 0039d316-1c4b-4281-b951-d872f2087c98

This converts BackendImpl to using FilePath.

BUG=24444

Review URL: http://codereview.chromium.org/261045

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28711 0039d316-1c4b-4281-b951-d872f2087c98

The sparse IO methods require exclusive use of the cache entry
and they complain when that requirement is violated. When the
user cancels a request and reissues another one to the same entry,
we may be waiting for the previous operation to finish when we
receive a new IO request, so we fail.

This CL add a way for the HTTP cache to cancel IO operations and
get a notification when the disk cache is able to operate on that
entry again.

BUG=23862
TEST=unittests

Review URL: http://codereview.chromium.org/256090

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28475 0039d316-1c4b-4281-b951-d872f2087c98

BUG=none
TEST=none


Review URL: http://codereview.chromium.org/182023

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24900 0039d316-1c4b-4281-b951-d872f2087c98

asynchronous IO.

BUG=none
TEST=none

Review URL: http://codereview.chromium.org/178023

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@24829 0039d316-1c4b-4281-b951-d872f2087c98

be able to return the key of an open entry.

Whenever a critical corruption is detected by the disk cache,
the backend disables itself and starts failing all requests
until it's able to re-create the backing store.

Key's longer than 928 bytes are not stored inside the entry
itself, so a file object is required to access them. The backend
will reject any request for a file object after it is disabled,
so a user's request for the key of an open entry will also
fail.

Now we keep a pointer to the related file object (if needed) so
that we don't have to ask the backend for it when the user
requests the current key.

BUG=9952
TEST=unittest


Review URL: http://codereview.chromium.org/165030

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22637 0039d316-1c4b-4281-b951-d872f2087c98

We now have a map of open entries so we don't need to
do a lookup through the rankings node anymore. This
simplifies the 64 bit version of the code.

BUG=17881
TEST=unittests

Review URL: http://codereview.chromium.org/159643

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22074 0039d316-1c4b-4281-b951-d872f2087c98

We were leaving empty block files in the chain, and worst
of all, not reusing them because we were thinking that these
files were "almost full". Now we also check for empty files
when the cache starts.

BUG=16740
TEST=unittest.


Review URL: http://codereview.chromium.org/159451

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21762 0039d316-1c4b-4281-b951-d872f2087c98

of sparse entries.

I started to add code to modify the children_map of the
parent entry when a child is evicted but that ended up
being too much trouble for too little gain. We have to be
prepared to handle the case of not finding a child entry
because there is no way to make sure that the process
doesn't go away at any time, so adding a lot of complexity
just to avoid an extra entry lookup is just not worth it.

On the other hand, potentially freeing up a lot of space when
a sparse entry is deleted (insetad of just waiting for the
eviction code to do the cleanup) seems like a good thing.

BUG=12258
TEST=unittest

Review URL: http://codereview.chromium.org/149306

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20325 0039d316-1c4b-4281-b951-d872f2087c98

We still have a few crashes when for some reason we believe
an entry is not dirty and we follow the pointer stored by
its rankings node only to crash while accessing the memory.
I have no explanation to why the dirty id matches the current
one (a page boundary issue maybe?), but having a map with all
open entries solves the issue of having to follow pointers
from disk.

BUG=15596, b/1120346
TEST=unittests

Review URL: http://codereview.chromium.org/149218

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20067 0039d316-1c4b-4281-b951-d872f2087c98

on the cache size.

BUG=10727
TEST=none

Review URL: http://codereview.chromium.org/146129

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19256 0039d316-1c4b-4281-b951-d872f2087c98

Adding Read/Write support.

BUG=12258
TEST=unittests.

original review: http://codereview.chromium.org/126179

Review URL: http://codereview.chromium.org/132031

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18772 0039d316-1c4b-4281-b951-d872f2087c98

TBR=nsylvain


git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18726 0039d316-1c4b-4281-b951-d872f2087c98

Adding Read/Write support.

BUG=12258
TEST=unittests.


Review URL: http://codereview.chromium.org/126179

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18723 0039d316-1c4b-4281-b951-d872f2087c98

This is just the interface declaration plus a mocked
implementation of the interface.

BUG=12258
TEST=none

Review URL: http://codereview.chromium.org/119072

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17669 0039d316-1c4b-4281-b951-d872f2087c98

Since the code now does range request without any caching
the code path for passing file handle is not used any more.

Changes:
1. Remove response_data_file in webkit_glue::ResourceResponseHead
2. Remove response_data_file in net::ResourceInfo
3. Remove code that passes file handle using IPC
4. Remove code that passes file hadnle from network layer to ResourceDispatcherHost
5. Remove MediaResourceHandler
6. Remove code in disk_cache that expose the file handle
7. Remove ChromeURLRequestContext::CreateOffTheRecordForMedia() so no more OTR request context for media, in OTR mode simply memory cache is used
8. Reset cache size for media cache to default

BUG=12249
BUG=12256

Review URL: http://codereview.chromium.org/113931

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17227 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/62176

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13431 0039d316-1c4b-4281-b951-d872f2087c98

"clean" is not really dirty.

If for some reason an entry is left on disk with a pointer
on the rankings node but without the dirty flag set, we now
recognize it as dirty the next time we read it from disk.

BUG=3987
TEST=DiskCacheTest.Backend_NotMarkedButDirty


Review URL: http://codereview.chromium.org/57024

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12820 0039d316-1c4b-4281-b951-d872f2087c98

of BackendImpl.

This cl takes care of all the histograms on the disk cache. Most
of them have to be splitted in three so that we get separate data
from different cache types. There are a few places where the complexity
of splitting the histogram is not worth it so we just keep either all
data together (if it makes sense), or just ignore data for some types of
caches.

note: Having multiple versions of a histogram but only one "active" for a
given client is not the same as having multiple histograms working at the
same time for different objects.

Review URL: http://codereview.chromium.org/42682

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12692 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/48155

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12028 0039d316-1c4b-4281-b951-d872f2087c98

other fixes related to the new eviction code. As before,
almost everything is disabled by default.


Review URL: http://codereview.chromium.org/48112

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11995 0039d316-1c4b-4281-b951-d872f2087c98

1. Added entry to ResourceResponseHead so that it contains
   either a base::PlatformFile (OS_WIN) or
   base::FileDescriptor (OS_POSIX) for passing the file
   handle from browser to renderer process.
2. Also added IPC messages for reporting download progress
   and ACK message for it. ResourceLoaderBridge::Peer::OnDownloadProgress
   is added so that the peer is notified of the download
   progress in the renderer process.
3. Load flag to kick start the resource loading for media
   files. LOAD_MEDIA_RESOURCE is added so that
   ResourceDispatcherHost knows how to use a different
   ResourceHandler for handling media resource request.

Review URL: http://codereview.chromium.org/27168

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11661 0039d316-1c4b-4281-b951-d872f2087c98

Disabled by a #def. When enabled, file format 2.1 is used,
with a possible update from ver 2.0. If a version with this
code disabled is run after the upgrade, it will just
discard the file and go back to 2.0.

We now put some of those extra list to use! Entries are
separated into various lists depending on how often are
used, and we keep track of previously evicted entries.

If the new algorithm is not enabled, most of the code just
goes through a different path (with the old code instead of
the new one). One notable exception is OpenFollowingEntry,
used to enumerate the entries on the cache; the code changed
significantly to support the new version of the "cache
iterator", but functionally should do the same as the current
code.


Review URL: http://codereview.chromium.org/27345

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@11145 0039d316-1c4b-4281-b951-d872f2087c98

Highlights of changes:
- Added methods to disk_cache::Entry:
  - Entry::PrepareTargetAsExternalFile(int index)
    Prepare a stream in an entry to use external file for storage.
  - Entry::GetExternalFile(int index)
    Get the external file backing the stream in the entry.
- Added a property "CacheType type_" to HttpCache, along with setter and getter.
  There shall be two cache types, COMMON_CACHE and MEDIA_CACHE for distinguishing between different purpose of HttpCache. We have this property to trigger special behavior for caching needs of media files.
- Added static methods to ChromeURLRequestContext
  - ChromeURLRequestContext::CreateOriginalForMedia
    Create a URLRequestContext for media files for the original profile.
  - ChromeURLRequestContext::CreateOffTheRecordForMedia
    Create a URLRequestContext for media files for off the record profile.
- Added method to Profile interface.
  - GetRequestContextForMedia
    To get the request context for media files from the context.

Design decissions:
- Enforce writing to external file by calling methods to Entry rather than construct Backend by a different flag.
  Since we only want a valid and full response to go into an external file rather than redirection response or erroneous response, we should let HttpCache::Transaction to decide when to have an external file for response data. We eliminate a lot of useless external cache files.
- Adding the CacheType enum and property to HttpCache, we could allow possible (?) future extensions to HttpCache to handle other different caching needs. And there's no need to add change constructors of HttpCache, but maybe we should add a specific constructor to accomodate a media HttpCache?
- Adding Profile::GetRequestContextForMedia()
  Since we will need to use this new request context in ResourceDispatcherHost, I think the best place to keep it is in the profile. Also we will expose to user that there's a separate cache for media, so it's better to expose it in the Profile level to allow settings to the media cache, e.g. max file size, etc.

Review URL: http://codereview.chromium.org/19747

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10745 0039d316-1c4b-4281-b951-d872f2087c98

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

This is cleanup from bug 5325.

Original code review: http://codereview.chromium.org/20134/show


Review URL: http://codereview.chromium.org/20251

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9626 0039d316-1c4b-4281-b951-d872f2087c98

Review URL: http://codereview.chromium.org/21236

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9532 0039d316-1c4b-4281-b951-d872f2087c98

This is cleanup from bug 5325.

Review URL: http://codereview.chromium.org/20134

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9528 0039d316-1c4b-4281-b951-d872f2087c98

The rankings module now works with any list, not just
the first one. This is part of the support needed for
new eviction algorithms.

note: Rankings::CheckList() is basically the code that
was implementing the old Rankings::SelfCheck() (moved
with this cl).

The disk cache behavior is not changing with this cl.

Review URL: http://codereview.chromium.org/14141

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@7074 0039d316-1c4b-4281-b951-d872f2087c98

This is the first step to allow the http cache to store additional metadata
for certain entries.

The cache file format changes to version 2.0 so an effect of this cl is
that the borwser will discard the old cache files.

Review URL: http://codereview.chromium.org/12880

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6392 0039d316-1c4b-4281-b951-d872f2087c98

another.

Also moves crash_cache project to the "tools folder" on the solution.
Review URL: http://codereview.chromium.org/12851

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@6226 0039d316-1c4b-4281-b951-d872f2087c98

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

Review URL: http://codereview.chromium.org/7995

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4022 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98

TEST=unit test


git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1270 0039d316-1c4b-4281-b951-d872f2087c98

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1067 0039d316-1c4b-4281-b951-d872f2087c98