[Webkit-unassigned] [Bug 25436] Refactor appCache for use in multi-process browsers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=25436


ap at webkit.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs at apple.com
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




------- Comment #2 from ap at webkit.org  2009-05-01 01:45 PDT -------
(In reply to comment #1)
> When built into a single process

Having a separate thread for appcache doesn't feel natural to me. It's just a
part of the loader, why should it have a life of its own?

It is true that some appcache operations are rather time consuming, and it may
be nice to move them to a secondary thread. Two distinct examples are loading
from disk database and prefix lookup for fallback.

The patch does not include any examples of how the new interfaces will be used
in loader. It is not clear if there are many calls that can be made
asynchronous. E.g., ResourceLoader::load() needs to look up appcache resources
synchronously before creating a ResourceHandle, and
ResourceLoader::willSendRequest() needs to do the same before returning.

> When built into a multi-process

I don't know how resource loading is implemented in Chromium sufficiently well
to comment. Maybe it would make sense to discuss this on the mailing list in
order to determine whether this should be a model for other projects
potentially using WebKit in multi-process configuration.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.