[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





------- Comment #1 from michaeln at google.com  2009-04-30 13:55 PDT -------
Created an attachment (id=29920)
 --> (https://bugs.webkit.org/attachment.cgi?id=29920&action=view)
outline of some interfaces

Hello, The attached patch is obviously not ready for submission. I'm fishing
for feedback on the general direction and the interfaces.

Some comments on how I see these classes being used in a single-process model
vs a multi-process model.

When built into a single process

* the 'backend' appache code is NOT used on the 'main' webkit thread
* for the sake of discussion, lets call the thread it is used on the
'backend' webkit thread
* the single process 'frontend' classes post tasks to the backend thread
* sync apis are handled by waiting on a WaitableEvent in the frontend
classes, which the will get signaled by the backend thread when done
* async api completion is handled by posting tasks to the 'main'
thread (probably easier to setup than having the main thead wait for
multple waitable event handles in the main message loop)
* generally, backend classes running on the 'backend' thread don't
block that thread for file io. Any blocking file io work gets pushed
off to a seperate file io handling thread(s). (This is similar to what
we require of code that executes on chrome's IPC thread in the main
browser process)

When built into a multi-process

* the 'backend' code is NOT used in the renderer at all
* it is used on the IPC thread in the main browser process (and it
doesn't block that thread)
* the multiprocess 'frontend' classes send IPC message instead of
posting thread tasks (sync and async)
* the 'frontend' code is NOT used in the browser process all all


-- 
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.