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
>
>
>>
>> >> I have always felt like running the WebCore "backend" in the browser
>> >> was elegant
>> >
>> > Yea, but we need a webcore backend to run :)
>>
>> Well last time I looked at this there was already a Database backend :)
>>
>> - a
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
