On Thu, Apr 30, 2009 at 12:26 PM, Michael Nordman <micha...@google.com> wrote:
> On Thu, Apr 30, 2009 at 11:40 AM, Darin Fisher <da...@chromium.org> wrote:
>> On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman <a...@chromium.org> wrote:
>>>
>>> On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman <micha...@chromium.org>
>>> wrote:
>>> >
>>> > + chromium-dev
>>> >
>>> >> Can you please explain what you think has changed since such decisions
>>> >> were made (or why it's time to revisit such decisions)?
>>> >
>>> > I don't think there was code in webcore suitable for this purpose
>>> > before... html parsing, javascript,sql interpretting... all dangerous
>>> > from a security point of view (acting in very complex ways on
>>> > untrusted web content). The backend logic for these new features
>>> > aren't like that. Its not so much that its webcore code is untrusted,
>>> > as much as the data it operates on is untrusted.
>>>
>>> I think this gets at the core of my question: is it OK to run webcore
>>> code in the browser process if it is similar in nature to chromium
>>> code we would run in the browser process? Or is there some deeper
>>> structural reason we don't want to do that?
>>>
>>> I fear that this is really a question for Darin, who is on vacation.
>>
>> can talk more when i get back, but in a nut shell:
>> 1- we already use webcore indirectly (albeit in a very limited way) from the
>> browser process
>> 2- the challenge with doing so is threading: what is the webcore main
>> thread? what things depend on this and what don't is not well defined.
>> -darin
>
> I've been thinking thru how to share the backend appcache code and
> have some thoughts on the threading issue.
>
> When built into a single process (so not the chrome situation)
>
> * 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 chrome
>
> * 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
In this view...
* The 'main' webkit thread is free to be the UI thead in the browser
process. I don't think we have a need for this for the appcache or
localstorage systems yet... but perhaps when it comes time to prompt
users for things or alert them to quota excesses and such this could
become relevant for those system.
* the 'backend' webkit thread == the IPC thread in the browser process
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
