Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Maciej Stachowiak]

On Feb 10, 2013, at 10:48 AM, Adam Barth  wrote:

> 
> 
> Ok.  I'm sold.  I suspect we'll want to move the iOS port off of 
> USE(WEB_THREAD), but I can see how it's better to do that work in trunk.

We definitely want to get off the web thread over time. There's two paths by 
which this will start happening in the short to medium term:
- We'll likely want to offer opt-in for clients to a lockless pure 
message-passing model (I can't share details or timelines but it's probably a 
good guess that it would involve WebKit2 abstractions)
- We'll want to pare away as much of the web-thread-related code as we can 
without breaking clients that haven't migrated.

Unfortunately there are public APIs on iOS that are hard to fulfill with a 
cleaner concurrency model so it will likely take a while to be fully rid of it.

>  I wonder if it would be worth using a name like USE(DEPRECATED_WEB_THREAD) 
> to discourage others from adopting this execution model.


How about USE(LEGACY_WEB_THREAD) or USE(IOS_LEGACY_WEB_THREAD)? That would 
correctly convey that ports should not adopt it, without putting it on quite 
the same level as Deprecated classes that are further on the path to removal.

Any new port that wants to avoid blocking the UI with web content processing 
should definitely *not* use the Web Thread, and instead should use the WebKit2 
or Chromium architectures (possibly including the threaded models offered by 
those).

(Also it should probably be an ENABLE, not a USE.)

> Thanks everyone for taking the time to discuss this issue.

Likewise.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Adam Barth]

On Sun, Feb 10, 2013 at 10:39 AM, Ojan Vafai  wrote:

> On Sat, Feb 9, 2013 at 7:41 PM, Maciej Stachowiak  wrote:
>
>>
>> Hi Peter,
>>
>> On Feb 9, 2013, at 3:48 PM, Peter Kasting  wrote:
>>
>> On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak  wrote:
>>
>>> There are certainly pros and cons to merging. It would be great get
>>> input from the broader WebKit community on the tradeoff of merging sooner
>>> vs avoidance of weird legacy code in the main tree. In the meantime, we'll
>>> stick to merging things that are not overly controversial as much as we can.
>>>
>>
>> For what my opinion is worth (probably near zero for a lot of you), I
>> would like to see you guys merge sooner rather than later, even if it leads
>> to awkwardness that needs cleanup.  Over the years there has been a nonzero
>> amount of friction due to the iOS port not being upstreamed, and I think it
>> would be beneficial to WebKit as a whole to fix that sooner rather than
>> later.  And it seems more likely to me that "upstream first, then decide
>> how to re-architect as needed" is going to result in high-quality
>> discussions and designs, as opposed to "figure out in private how to
>> re-architect before upstreaming", which runs the risk of just never
>> bothering to upstream at all.
>>
>> There is real compromise, and perhaps humility, needed from all sides to
>> make such a task successful.  I am reminded of Eric's recent email where he
>> pleaded for more of an explicit effort to civility towards each other.
>>  Perhaps this is an opportunity for us to practice that effort.
>>
>>
>> I really appreciate you saying that. I feel the same way. For years we've
>> been saying that we need to fix N different things before upstreaming, and
>> in the end we concluded that it was just delaying us from upstreaming at
>> all. And we concluded that cleaning up some of the questionable choices in
>> the open would lead to a better final outcome.
>>
>
> +1. I think that allowing the V8 bindings into the tree is a fairly good
> analogy to this situation (although it's not exactly the same). The point
> is that it did put a burden on the rest of the project at the benefit of
> getting Chromium folk working on core code and giving the ability to
> discuss trade-offs more directly by looking at the code in question.
>

Ok.  I'm sold.  I suspect we'll want to move the iOS port off of
USE(WEB_THREAD), but I can see how it's better to do that work in trunk.  I
wonder if it would be worth using a name like USE(DEPRECATED_WEB_THREAD) to
discourage others from adopting this execution model.

Thanks everyone for taking the time to discuss this issue.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Ojan Vafai]

On Sat, Feb 9, 2013 at 7:41 PM, Maciej Stachowiak  wrote:

>
> Hi Peter,
>
> On Feb 9, 2013, at 3:48 PM, Peter Kasting  wrote:
>
> On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak  wrote:
>
>> There are certainly pros and cons to merging. It would be great get input
>> from the broader WebKit community on the tradeoff of merging sooner vs
>> avoidance of weird legacy code in the main tree. In the meantime, we'll
>> stick to merging things that are not overly controversial as much as we can.
>>
>
> For what my opinion is worth (probably near zero for a lot of you), I
> would like to see you guys merge sooner rather than later, even if it leads
> to awkwardness that needs cleanup.  Over the years there has been a nonzero
> amount of friction due to the iOS port not being upstreamed, and I think it
> would be beneficial to WebKit as a whole to fix that sooner rather than
> later.  And it seems more likely to me that "upstream first, then decide
> how to re-architect as needed" is going to result in high-quality
> discussions and designs, as opposed to "figure out in private how to
> re-architect before upstreaming", which runs the risk of just never
> bothering to upstream at all.
>
> There is real compromise, and perhaps humility, needed from all sides to
> make such a task successful.  I am reminded of Eric's recent email where he
> pleaded for more of an explicit effort to civility towards each other.
>  Perhaps this is an opportunity for us to practice that effort.
>
>
> I really appreciate you saying that. I feel the same way. For years we've
> been saying that we need to fix N different things before upstreaming, and
> in the end we concluded that it was just delaying us from upstreaming at
> all. And we concluded that cleaning up some of the questionable choices in
> the open would lead to a better final outcome.
>

+1. I think that allowing the V8 bindings into the tree is a fairly good
analogy to this situation (although it's not exactly the same). The point
is that it did put a burden on the rest of the project at the benefit of
getting Chromium folk working on core code and giving the ability to
discuss trade-offs more directly by looking at the code in question.


> At the same time, I think some scrutiny of what we are doing is fair, so
> I'll try to explain the threading issues in a bit more detail to the extent
> I can.
>
> Regards,
> Maciej
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Maciej Stachowiak]

Hi Peter,

On Feb 9, 2013, at 3:48 PM, Peter Kasting  wrote:

> On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak  wrote:
> There are certainly pros and cons to merging. It would be great get input 
> from the broader WebKit community on the tradeoff of merging sooner vs 
> avoidance of weird legacy code in the main tree. In the meantime, we'll stick 
> to merging things that are not overly controversial as much as we can.
> 
> For what my opinion is worth (probably near zero for a lot of you), I would 
> like to see you guys merge sooner rather than later, even if it leads to 
> awkwardness that needs cleanup.  Over the years there has been a nonzero 
> amount of friction due to the iOS port not being upstreamed, and I think it 
> would be beneficial to WebKit as a whole to fix that sooner rather than 
> later.  And it seems more likely to me that "upstream first, then decide how 
> to re-architect as needed" is going to result in high-quality discussions and 
> designs, as opposed to "figure out in private how to re-architect before 
> upstreaming", which runs the risk of just never bothering to upstream at all.
> 
> There is real compromise, and perhaps humility, needed from all sides to make 
> such a task successful.  I am reminded of Eric's recent email where he 
> pleaded for more of an explicit effort to civility towards each other.  
> Perhaps this is an opportunity for us to practice that effort.

I really appreciate you saying that. I feel the same way. For years we've been 
saying that we need to fix N different things before upstreaming, and in the 
end we concluded that it was just delaying us from upstreaming at all. And we 
concluded that cleaning up some of the questionable choices in the open would 
lead to a better final outcome.

At the same time, I think some scrutiny of what we are doing is fair, so I'll 
try to explain the threading issues in a bit more detail to the extent I can.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Maciej Stachowiak]

On Feb 9, 2013, at 3:01 PM, James Robinson  wrote:

> 
> 
> On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak  wrote:
> 
> 
> P.S. "Running WebCore on interlocking threads" is a needlessly scary way to 
> describe what iOS WebKit does. There is no complex fine-grained locking or 
> actual parallel execution. It's more like what would happen if you ran WebKit 
> on a GCD dispatch queue or a thread in a userspace M:N threading library, 
> instead of on an underlying OS-level thread (really it's a restricted subset 
> of that). As such, it has very little impact on WebCore and below. Mainly it 
> just requires that the threading primitives have an appropriate platform 
> implementation on iOS.
> 
> http://trac.webkit.org/changeset/141812 
> (https://bugs.webkit.org/show_bug.cgi?id=108139) added fine-grain locking to 
> the AtomicString table in order to support the iOS WebKit threading model.  
> If parallel execution is not possible, why would this need locking?

This is one of the few pieces of code that gets touched for other threads, 
mainly because pieces of WebCore get used for some non-Web-content-related 
drawing. I'll have to do research if you want to know in more detail.

Because it's the weekend and I have the copious free time, I will go over the 
full set of diffs and post a full list of the threading-model-related changes 
that are required in WebCore and below. I expect it to be surprisingly short 
and low-impact, but I will post it even if it looks grim.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Peter Kasting]

On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak  wrote:

> There are certainly pros and cons to merging. It would be great get input
> from the broader WebKit community on the tradeoff of merging sooner vs
> avoidance of weird legacy code in the main tree. In the meantime, we'll
> stick to merging things that are not overly controversial as much as we can.
>

For what my opinion is worth (probably near zero for a lot of you), I would
like to see you guys merge sooner rather than later, even if it leads to
awkwardness that needs cleanup.  Over the years there has been a nonzero
amount of friction due to the iOS port not being upstreamed, and I think it
would be beneficial to WebKit as a whole to fix that sooner rather than
later.  And it seems more likely to me that "upstream first, then decide
how to re-architect as needed" is going to result in high-quality
discussions and designs, as opposed to "figure out in private how to
re-architect before upstreaming", which runs the risk of just never
bothering to upstream at all.

There is real compromise, and perhaps humility, needed from all sides to
make such a task successful.  I am reminded of Eric's recent email where he
pleaded for more of an explicit effort to civility towards each other.
 Perhaps this is an opportunity for us to practice that effort.

PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Benjamin Poulain]

On Sat, Feb 9, 2013 at 3:01 PM, James Robinson  wrote:

> http://trac.webkit.org/changeset/141812 (
> https://bugs.webkit.org/show_bug.cgi?id=108139) added fine-grain locking
> to the AtomicString table in order to support the iOS WebKit threading
> model.  If parallel execution is not possible, why would this need locking?
>

That code does not make AtomicString thread safe in any way.

If I remember correctly, that code is related to races at initializations.
I can dig the history on Monday if you'd like.

Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[James Robinson]

On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak  wrote:

>
> On Feb 9, 2013, at 10:11 AM, Adam Barth  wrote:
>
> On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak  wrote:
>
>>
>> On Feb 8, 2013, at 2:33 PM, Darin Fisher  wrote:
>>
>> I would recommend minimizing the re-architecture of WebCore as you are in
>> the early stages of upstreaming.  It seems like you already have a working
>> port that you could simply upstream.  You could then work with others in
>> the community to introduce new concepts to WebCore with the full disclosure
>> of code as an aide to the process.  Another option might be to open source
>> the entire thing as a branch somewhere.
>>
>>
>> After the initial upstreaming or sharing of code is complete, you could
>> then catalog all of the warts.  The fact that isMainThread returns true
>> when called on more than one thread would be one such wart.  I can imagine
>> a meta bug tracking all of these warts.  This would make it a lot easier
>> for others to understand the overall change in direction needed for WebKit
>> to properly support the iOS port.
>>
>> That's approximately what we're planning to do. We are upstreaming
>> incrementally, starting with simple pieces, and documenting issues. The bug
>> that sparked this thread was a relatively change to isMainThread(), plus a
>> function rename, and we are no longer asking for the function rename. It
>> will likely be a dozen line patch touching a single mac/ios-specific file.
>>
>> We'd really like to fully upstream the simpler components like WTF (where
>> the changes are all simple and targeted) even if we can't as easily do
>> WebCore (where there may be more complex and controversial diffs).
>>
>
> From what you've said, it sounds like this issue doesn't apply to WebKit2
> on iOS.
>
>
> (1) What WebKit2 on iOS? We have not announced or shipped such a thing.
> The code used by MobileSafari, and by third party apps like the embedded
> browser in Twitter, or Chrome for iOS is a WebKit1 based port.
>
> (2) You might reasonably guess that WebKit2 on iOS is a plausible future
> direction. If we did do it, then as on Mac we would consider it a
> requirement for it to use the same binaries for WebCore and lower (though
> we'd turn off the Web Thread at runtime).
>
> Perhaps we should focus on merging WebKit2 into trunk and delay having to
> worry about running WebCore on multiple interlocking threads.
>
>
> This suggestion is approximately equivalent to "let's not merge yet", for
> reasons stated above.
>
> There are certainly pros and cons to merging. It would be great get input
> from the broader WebKit community on the tradeoff of merging sooner vs
> avoidance of weird legacy code in the main tree. In the meantime, we'll
> stick to merging things that are not overly controversial as much as we can.
>
> Regards,
> Maciej
>
>
> P.S. "Running WebCore on interlocking threads" is a needlessly scary way
> to describe what iOS WebKit does. There is no complex fine-grained locking
> or actual parallel execution. It's more like what would happen if you ran
> WebKit on a GCD dispatch queue or a thread in a userspace M:N threading
> library, instead of on an underlying OS-level thread (really it's a
> restricted subset of that). As such, it has very little impact on WebCore
> and below. Mainly it just requires that the threading primitives have an
> appropriate platform implementation on iOS.
>

http://trac.webkit.org/changeset/141812 (
https://bugs.webkit.org/show_bug.cgi?id=108139) added fine-grain locking to
the AtomicString table in order to support the iOS WebKit threading model.
 If parallel execution is not possible, why would this need locking?

- James



>
> For anyone interested in learning more about this, I think Ben had the
> best high-level explanation: <
> https://bugs.webkit.org/show_bug.cgi?id=109071#c14>. We can also provide
> more detail if desired.
>

>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Maciej Stachowiak]

On Feb 9, 2013, at 10:11 AM, Adam Barth  wrote:

> On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak  wrote:
> 
> On Feb 8, 2013, at 2:33 PM, Darin Fisher  wrote:
>> I would recommend minimizing the re-architecture of WebCore as you are in 
>> the early stages of upstreaming.  It seems like you already have a working 
>> port that you could simply upstream.  You could then work with others in the 
>> community to introduce new concepts to WebCore with the full disclosure of 
>> code as an aide to the process.  Another option might be to open source the 
>> entire thing as a branch somewhere.
> 
>> 
>> After the initial upstreaming or sharing of code is complete, you could then 
>> catalog all of the warts.  The fact that isMainThread returns true when 
>> called on more than one thread would be one such wart.  I can imagine a meta 
>> bug tracking all of these warts.  This would make it a lot easier for others 
>> to understand the overall change in direction needed for WebKit to properly 
>> support the iOS port.
> 
> That's approximately what we're planning to do. We are upstreaming 
> incrementally, starting with simple pieces, and documenting issues. The bug 
> that sparked this thread was a relatively change to isMainThread(), plus a 
> function rename, and we are no longer asking for the function rename. It will 
> likely be a dozen line patch touching a single mac/ios-specific file.
> 
> We'd really like to fully upstream the simpler components like WTF (where the 
> changes are all simple and targeted) even if we can't as easily do WebCore 
> (where there may be more complex and controversial diffs).
> 
> From what you've said, it sounds like this issue doesn't apply to WebKit2 on 
> iOS. 

(1) What WebKit2 on iOS? We have not announced or shipped such a thing. The 
code used by MobileSafari, and by third party apps like the embedded browser in 
Twitter, or Chrome for iOS is a WebKit1 based port.

(2) You might reasonably guess that WebKit2 on iOS is a plausible future 
direction. If we did do it, then as on Mac we would consider it a requirement 
for it to use the same binaries for WebCore and lower (though we'd turn off the 
Web Thread at runtime).

> Perhaps we should focus on merging WebKit2 into trunk and delay having to 
> worry about running WebCore on multiple interlocking threads.

This suggestion is approximately equivalent to "let's not merge yet", for 
reasons stated above.

There are certainly pros and cons to merging. It would be great get input from 
the broader WebKit community on the tradeoff of merging sooner vs avoidance of 
weird legacy code in the main tree. In the meantime, we'll stick to merging 
things that are not overly controversial as much as we can.

Regards,
Maciej


P.S. "Running WebCore on interlocking threads" is a needlessly scary way to 
describe what iOS WebKit does. There is no complex fine-grained locking or 
actual parallel execution. It's more like what would happen if you ran WebKit 
on a GCD dispatch queue or a thread in a userspace M:N threading library, 
instead of on an underlying OS-level thread (really it's a restricted subset of 
that). As such, it has very little impact on WebCore and below. Mainly it just 
requires that the threading primitives have an appropriate platform 
implementation on iOS.

For anyone interested in learning more about this, I think Ben had the best 
high-level explanation: . 
We can also provide more detail if desired.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Adam Barth]

On Fri, Feb 8, 2013 at 8:19 PM, Maciej Stachowiak  wrote:

>
> On Feb 8, 2013, at 2:33 PM, Darin Fisher  wrote:
>
> I would recommend minimizing the re-architecture of WebCore as you are in
> the early stages of upstreaming.  It seems like you already have a working
> port that you could simply upstream.  You could then work with others in
> the community to introduce new concepts to WebCore with the full disclosure
> of code as an aide to the process.  Another option might be to open source
> the entire thing as a branch somewhere.
>
>
> After the initial upstreaming or sharing of code is complete, you could
> then catalog all of the warts.  The fact that isMainThread returns true
> when called on more than one thread would be one such wart.  I can imagine
> a meta bug tracking all of these warts.  This would make it a lot easier
> for others to understand the overall change in direction needed for WebKit
> to properly support the iOS port.
>
> That's approximately what we're planning to do. We are upstreaming
> incrementally, starting with simple pieces, and documenting issues. The bug
> that sparked this thread was a relatively change to isMainThread(), plus a
> function rename, and we are no longer asking for the function rename. It
> will likely be a dozen line patch touching a single mac/ios-specific file.
>
> We'd really like to fully upstream the simpler components like WTF (where
> the changes are all simple and targeted) even if we can't as easily do
> WebCore (where there may be more complex and controversial diffs).
>

>From what you've said, it sounds like this issue doesn't apply to WebKit2
on iOS.  Perhaps we should focus on merging WebKit2 into trunk and delay
having to worry about running WebCore on multiple interlocking threads.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Maciej Stachowiak]

On Feb 8, 2013, at 2:33 PM, Darin Fisher  wrote:

> 
> 
> 
> If we'd taken an equally hard line when Google wanted to merge the Chromium 
> port to trunk, with a number of design choices in place that we didn't agree 
> with but which were hard to change, it probably still wouldn't be in the tree 
> to this day. I don't think that would have been a good thing for the WebKit 
> project.
> 
> I think this is a bit different.
> 
> For the Chromium port, we started out with the assumption that we couldn't 
> easily change much about the architecture of WebCore.  Instead, we tried to 
> make Chromium match the set of constraints imposed on WebCore by WebKit, 
> CFNetwork, CoreGraphics and more recently CoreAnimation.
> 
> This led to things like hiding the details of the out-of-process network 
> stack behind ResourceHandle.  We did so because we assumed that it would make 
> our port less of a burden to others.

The example I was thinking of was adding support for an alternate JavaScript 
engine. If we'd stood firm on objections to that, it's unlikely Chromium would 
be in the tree. I'm glad we yielded on our objections there, even though 
there's some ongoing cost to the project from supporting two different JS 
engines. This is not to rehash old battles - I'm just suggesting that applying 
a little pragmatism may be appropriate.

> 
> 
> I am curious how others feel about the value of merging the iOS port back to 
> trunk as soon as possible, vs. the need to fix all of the past design 
> decisions in this port that may be disputed.
> 
> I think it is valuable to upstream the iOS port.  I'm sad that it has not 
> happened sooner.  Many times, the architecture of the iOS port has been used 
> as justification by Apple engineers for why WebCore should work a certain 
> way.  It is often not obvious from the open source code that such constraints 
> exist.  Having the code in the open would seem to help with such issues.

Thanks for acknowledging the benefits.

> 
> I would recommend minimizing the re-architecture of WebCore as you are in the 
> early stages of upstreaming.  It seems like you already have a working port 
> that you could simply upstream.  You could then work with others in the 
> community to introduce new concepts to WebCore with the full disclosure of 
> code as an aide to the process.  Another option might be to open source the 
> entire thing as a branch somewhere.
> 
> After the initial upstreaming or sharing of code is complete, you could then 
> catalog all of the warts.  The fact that isMainThread returns true when 
> called on more than one thread would be one such wart.  I can imagine a meta 
> bug tracking all of these warts.  This would make it a lot easier for others 
> to understand the overall change in direction needed for WebKit to properly 
> support the iOS port.

That's approximately what we're planning to do. We are upstreaming 
incrementally, starting with simple pieces, and documenting issues. The bug 
that sparked this thread was a relatively change to isMainThread(), plus a 
function rename, and we are no longer asking for the function rename. It will 
likely be a dozen line patch touching a single mac/ios-specific file.

We'd really like to fully upstream the simpler components like WTF (where the 
changes are all simple and targeted) even if we can't as easily do WebCore 
(where there may be more complex and controversial diffs).

Cheers,
Maciej




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Maciej Stachowiak]

On Feb 8, 2013, at 4:48 PM, Adam Barth  wrote:

> 
> One simple example is V8, which stores the current v8::Isolate in
> thread-local storage.
> 
> However, the problem is certainly not limited to V8, nor is it even
> limited to the code we're using today.  Running WebCore on multiple
> interlocked threads imposes restrictions on how all the code called by
> WebCore use TLS.  Those restrictions might be worthwhile or they might
> not be worthwhile.

I think "running WebCore on multiple interlocked threads" is not a good 
description of how the iOS threading model works. See my other message. I'd be 
glad to explain it in more detail, if you would like to understand how it works.


> Before adding these restrictions to WebCore, we should discuss them as
> a community and come to consensus about whether their benefits
> outweigh their costs.  I don't think it's appropriate for Apple to
> impose these restrictions on WebCore unilaterally.

There's not really significant "restrictions to WebCore" - the code exists and 
is shipping for years, and we've never experienced issues with TLS  in the way 
you are concerned about. Probably because the use of WebCore from the main 
thread is quite limited.

If you want to see for yourself, uou can see the fallout in the iOS WebCore 
tarball dumps that Apple offers. Or we can walk you through it in person. It's 
probably not practical to explain in full detail by email.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Adam Barth]

On Fri, Feb 8, 2013 at 4:56 PM, Maciej Stachowiak  wrote:
> On Feb 8, 2013, at 4:14 PM, Adam Barth  wrote:
>> On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer  wrote:
>>> On Feb 8, 2013, at 2:52 PM, Adam Barth  wrote:
 On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer  wrote:
> The iOS port does not require re-architecting WebCore.
>
> Bug 109071 was about coming up with a better name for a method that is 
> primarily used in ASSERT()s in WebCore.  Without changing the 
> implementation of that method, debug builds of WebCore on iOS assert 
> instantly since WebCore execution can happen on one of two threads.
>
> We can live with keeping the method name as "isMainThread()" and have 
> already moved on to other things.
>
> The rest of WebCore is largely unchanged for iOS, other than the usual 
> port-specific code you need for a port, which will be posted for review 
> as we continue to merge.

 How do these multiple interlocked threads interact with code that uses
 thread-local storage?
>>>
>>> The UI (main) thread and the web thread share the same thread-local 
>>> storage.  Those code changes are in 4 or 5 files in WTF.
>>
>> How does that work for code called by WebCore that doesn't use WTF's
>> TLS abstractions?
>
> To clarify the overall iOS WebKit threading model:
>
> - Essentially all Web content processing happens on the "Web thread" instead 
> of the main thread. This is approximately isomorphic to how Chromium puts Web 
> content processing in a separate render process, or how WebKit2 puts web 
> content processing into a Web Process.
>
> - Because this work was originally done in a hastier way and with less clear 
> design, it does not do as good a job as Chromium or WebKit2 at sticking 
> strictly to message passing. There are a tiny handful of pieces of WebCore 
> code that get touched directly by the WebKit layer on the main thread. But 
> this is the exception.
>
> We don't have a model where web content processing is broadly spread across 
> multiple thread. We just have a few regrettable (but tricky to fix) 
> exceptions to a message-passing model that processes Web content on a 
> background thread.
>
> I hope this context helps you understand people's answers, and why we believe 
> there is very little impact on WebCore from this change.

Why should the entire WebKit project pay the price for this hasty
design in the iOS fork?

It sounds like this issue is limited to WebKit1.  Perhaps the best
path forward is to upstream the iOS version of WebKit2 and let the
mistakes of WebKit1 on iOS lay fallow.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Maciej Stachowiak]

On Feb 8, 2013, at 4:14 PM, Adam Barth  wrote:

> On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer  wrote:
>> On Feb 8, 2013, at 2:52 PM, Adam Barth  wrote:
>>> On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer  wrote:
 The iOS port does not require re-architecting WebCore.
 
 Bug 109071 was about coming up with a better name for a method that is 
 primarily used in ASSERT()s in WebCore.  Without changing the 
 implementation of that method, debug builds of WebCore on iOS assert 
 instantly since WebCore execution can happen on one of two threads.
 
 We can live with keeping the method name as "isMainThread()" and have 
 already moved on to other things.
 
 The rest of WebCore is largely unchanged for iOS, other than the usual 
 port-specific code you need for a port, which will be posted for review as 
 we continue to merge.
>>> 
>>> How do these multiple interlocked threads interact with code that uses
>>> thread-local storage?
>> 
>> The UI (main) thread and the web thread share the same thread-local storage. 
>>  Those code changes are in 4 or 5 files in WTF.
> 
> How does that work for code called by WebCore that doesn't use WTF's
> TLS abstractions?

Hi Adam,

To clarify the overall iOS WebKit threading model:

- Essentially all Web content processing happens on the "Web thread" instead of 
the main thread. This is approximately isomorphic to how Chromium puts Web 
content processing in a separate render process, or how WebKit2 puts web 
content processing into a Web Process.

- Because this work was originally done in a hastier way and with less clear 
design, it does not do as good a job as Chromium or WebKit2 at sticking 
strictly to message passing. There are a tiny handful of pieces of WebCore code 
that get touched directly by the WebKit layer on the main thread. But this is 
the exception.

We don't have a model where web content processing is broadly spread across 
multiple thread. We just have a few regrettable (but tricky to fix) exceptions 
to a message-passing model that processes Web content on a background thread.

I hope this context helps you understand people's answers, and why we believe 
there is very little impact on WebCore from this change.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Adam Barth]

On Fri, Feb 8, 2013 at 4:29 PM, Pratik Solanki  wrote:
> On Feb 8, 2013, at 4:14 PM, Adam Barth  wrote:
>> On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer  wrote:
>>> On Feb 8, 2013, at 2:52 PM, Adam Barth  wrote:
 On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer  wrote:
> The iOS port does not require re-architecting WebCore.
>
> Bug 109071 was about coming up with a better name for a method that is 
> primarily used in ASSERT()s in WebCore.  Without changing the 
> implementation of that method, debug builds of WebCore on iOS assert 
> instantly since WebCore execution can happen on one of two threads.
>
> We can live with keeping the method name as "isMainThread()" and have 
> already moved on to other things.
>
> The rest of WebCore is largely unchanged for iOS, other than the usual 
> port-specific code you need for a port, which will be posted for review 
> as we continue to merge.

 How do these multiple interlocked threads interact with code that uses
 thread-local storage?
>>>
>>> The UI (main) thread and the web thread share the same thread-local 
>>> storage.  Those code changes are in 4 or 5 files in WTF.
>>
>> How does that work for code called by WebCore that doesn't use WTF's
>> TLS abstractions?
>
> Can you give an example? I've seen changes in Supplementable.h and WeakPtr.h 
> (in WTF) that assert about the thread id. For those, we're adding 
> PLATFORM(IOS) checks to check for both threads. Are there any others?

One simple example is V8, which stores the current v8::Isolate in
thread-local storage.

However, the problem is certainly not limited to V8, nor is it even
limited to the code we're using today.  Running WebCore on multiple
interlocked threads imposes restrictions on how all the code called by
WebCore use TLS.  Those restrictions might be worthwhile or they might
not be worthwhile.

Before adding these restrictions to WebCore, we should discuss them as
a community and come to consensus about whether their benefits
outweigh their costs.  I don't think it's appropriate for Apple to
impose these restrictions on WebCore unilaterally.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Pratik Solanki]

On Feb 8, 2013, at 4:14 PM, Adam Barth  wrote:

> On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer  wrote:
>> On Feb 8, 2013, at 2:52 PM, Adam Barth  wrote:
>>> On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer  wrote:
 The iOS port does not require re-architecting WebCore.
 
 Bug 109071 was about coming up with a better name for a method that is 
 primarily used in ASSERT()s in WebCore.  Without changing the 
 implementation of that method, debug builds of WebCore on iOS assert 
 instantly since WebCore execution can happen on one of two threads.
 
 We can live with keeping the method name as "isMainThread()" and have 
 already moved on to other things.
 
 The rest of WebCore is largely unchanged for iOS, other than the usual 
 port-specific code you need for a port, which will be posted for review as 
 we continue to merge.
>>> 
>>> How do these multiple interlocked threads interact with code that uses
>>> thread-local storage?
>> 
>> The UI (main) thread and the web thread share the same thread-local storage. 
>>  Those code changes are in 4 or 5 files in WTF.
> 
> How does that work for code called by WebCore that doesn't use WTF's
> TLS abstractions?

Can you give an example? I've seen changes in Supplementable.h and WeakPtr.h 
(in WTF) that assert about the thread id. For those, we're adding PLATFORM(IOS) 
checks to check for both threads. Are there any others?

Pratik
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Adam Barth]

On Fri, Feb 8, 2013 at 4:07 PM, David Kilzer  wrote:
> On Feb 8, 2013, at 2:52 PM, Adam Barth  wrote:
>> On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer  wrote:
>>> The iOS port does not require re-architecting WebCore.
>>>
>>> Bug 109071 was about coming up with a better name for a method that is 
>>> primarily used in ASSERT()s in WebCore.  Without changing the 
>>> implementation of that method, debug builds of WebCore on iOS assert 
>>> instantly since WebCore execution can happen on one of two threads.
>>>
>>> We can live with keeping the method name as "isMainThread()" and have 
>>> already moved on to other things.
>>>
>>> The rest of WebCore is largely unchanged for iOS, other than the usual 
>>> port-specific code you need for a port, which will be posted for review as 
>>> we continue to merge.
>>
>> How do these multiple interlocked threads interact with code that uses
>> thread-local storage?
>
> The UI (main) thread and the web thread share the same thread-local storage.  
> Those code changes are in 4 or 5 files in WTF.

How does that work for code called by WebCore that doesn't use WTF's
TLS abstractions?

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[David Kilzer]

On Feb 8, 2013, at 2:52 PM, Adam Barth  wrote:

> On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer  wrote:
> 
>> The iOS port does not require re-architecting WebCore.
>> 
>> Bug 109071 was about coming up with a better name for a method that is 
>> primarily used in ASSERT()s in WebCore.  Without changing the implementation 
>> of that method, debug builds of WebCore on iOS assert instantly since 
>> WebCore execution can happen on one of two threads.
>> 
>> We can live with keeping the method name as "isMainThread()" and have 
>> already moved on to other things.
>> 
>> The rest of WebCore is largely unchanged for iOS, other than the usual 
>> port-specific code you need for a port, which will be posted for review as 
>> we continue to merge.
> 
> How do these multiple interlocked threads interact with code that uses
> thread-local storage?


The UI (main) thread and the web thread share the same thread-local storage.  
Those code changes are in 4 or 5 files in WTF.

There are also a couple of additional mutexes in WebCore for WebSQL and the DOM 
wrapper cache.

Access to WebCore itself is mediated by a coarse-grained lock (the web thread 
lock), which is taken outside of WebCore.

Dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Adam Barth]

On Fri, Feb 8, 2013 at 2:45 PM, David Kilzer  wrote:
> On Feb 8, 2013, at 1:41 PM, Adam Barth  wrote:
>> Context: https://bugs.webkit.org/show_bug.cgi?id=109071
>> Adam Barth said:
>>> It's not clear to me that running WebCore on multiple interlocked threads 
>>> is a good idea.  That
>>> seems like a pretty major change to WebCore's architecture.  Is that 
>>> something that's up for
>>> discussion?
>>
>> Darin Adler said:
>>> I agree that it’s not something I’d do if I was starting a project now.
>>>
>>> In the iOS context, it’s fantastic for discussion as a possibly multi-year 
>>> major architecture
>>> change, but if we take a hard line on this, then we won’t have the iOS port 
>>> in the tree for
>>> years, and I think it would be good if we do. iOS WebKit has worked this 
>>> way for the entire
>>> history of iPhone, so it’s not a change that can be made easily.
>>
>> Darin Adler also said:
>>> I think where you and I may differ is on whether a good solution to the 
>>> problem would be
>>> valuable to the WebKit project. Is there some way I convince you of the 
>>> value of fitting
>>> an important existing port of WebKit into our tree in as clean as possible 
>>> a way?
>>
>> I don't really know how to respond to this thread.  I feel like I'm
>> being offered the following choice:
>>
>> 1) Give up the ability to have technical input to how WebCore works
>> and simply accept all the design choices made in the iOS fork, whether
>> they be good choices or bad.
>>
>> 2) Keep the iOS port in an Apple-internal fork for a number of years.
>>
>> I feel like I'm being asked to make this choice in the context of a
>> growing trend of unilateral action by Apple in this project.  Given
>> that trend, I don't see how I can choose option (1).
>>
>> As much as I would like the iOS port merged into trunk, I'm not
>> willing to give up having a technical say in the project.  Therefore,
>> reluctantly, I'm forced to choose option (2).
>
> The iOS port does not require re-architecting WebCore.
>
> Bug 109071 was about coming up with a better name for a method that is 
> primarily used in ASSERT()s in WebCore.  Without changing the implementation 
> of that method, debug builds of WebCore on iOS assert instantly since WebCore 
> execution can happen on one of two threads.
>
> We can live with keeping the method name as "isMainThread()" and have already 
> moved on to other things.
>
> The rest of WebCore is largely unchanged for iOS, other than the usual 
> port-specific code you need for a port, which will be posted for review as we 
> continue to merge.

How do these multiple interlocked threads interact with code that uses
thread-local storage?

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[David Kilzer]

On Feb 8, 2013, at 1:41 PM, Adam Barth  wrote:

> Context: https://bugs.webkit.org/show_bug.cgi?id=109071
> 
> Adam Barth said:
>> It's not clear to me that running WebCore on multiple interlocked threads is 
>> a good idea.  That
>> seems like a pretty major change to WebCore's architecture.  Is that 
>> something that's up for
>> discussion?
> 
> Darin Adler said:
>> I agree that it’s not something I’d do if I was starting a project now.
>> 
>> In the iOS context, it’s fantastic for discussion as a possibly multi-year 
>> major architecture
>> change, but if we take a hard line on this, then we won’t have the iOS port 
>> in the tree for
>> years, and I think it would be good if we do. iOS WebKit has worked this way 
>> for the entire
>> history of iPhone, so it’s not a change that can be made easily.
> 
> Darin Adler also said:
>> I think where you and I may differ is on whether a good solution to the 
>> problem would be
>> valuable to the WebKit project. Is there some way I convince you of the 
>> value of fitting
>> an important existing port of WebKit into our tree in as clean as possible a 
>> way?
> 
> I don't really know how to respond to this thread.  I feel like I'm
> being offered the following choice:
> 
> 1) Give up the ability to have technical input to how WebCore works
> and simply accept all the design choices made in the iOS fork, whether
> they be good choices or bad.
> 
> 2) Keep the iOS port in an Apple-internal fork for a number of years.
> 
> I feel like I'm being asked to make this choice in the context of a
> growing trend of unilateral action by Apple in this project.  Given
> that trend, I don't see how I can choose option (1).
> 
> As much as I would like the iOS port merged into trunk, I'm not
> willing to give up having a technical say in the project.  Therefore,
> reluctantly, I'm forced to choose option (2).


The iOS port does not require re-architecting WebCore.

Bug 109071 was about coming up with a better name for a method that is 
primarily used in ASSERT()s in WebCore.  Without changing the implementation of 
that method, debug builds of WebCore on iOS assert instantly since WebCore 
execution can happen on one of two threads.

We can live with keeping the method name as "isMainThread()" and have already 
moved on to other things.

The rest of WebCore is largely unchanged for iOS, other than the usual 
port-specific code you need for a port, which will be posted for review as we 
continue to merge.

Dave

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Darin Fisher]

On Fri, Feb 8, 2013 at 2:05 PM, Maciej Stachowiak  wrote:

>
> On Feb 8, 2013, at 1:41 PM, Adam Barth  wrote:
>
> > Context: https://bugs.webkit.org/show_bug.cgi?id=109071
> >
> > Adam Barth said:
> >> It's not clear to me that running WebCore on multiple interlocked
> threads is a good idea.  That
> >> seems like a pretty major change to WebCore's architecture.  Is that
> something that's up for
> >> discussion?
> >
> > Darin Adler said:
> >> I agree that it’s not something I’d do if I was starting a project now.
> >>
> >> In the iOS context, it’s fantastic for discussion as a possibly
> multi-year major architecture
> >> change, but if we take a hard line on this, then we won’t have the iOS
> port in the tree for
> >> years, and I think it would be good if we do. iOS WebKit has worked
> this way for the entire
> >> history of iPhone, so it’s not a change that can be made easily.
> >
> > Darin Adler also said:
> >> I think where you and I may differ is on whether a good solution to the
> problem would be
> >> valuable to the WebKit project. Is there some way I convince you of the
> value of fitting
> >> an important existing port of WebKit into our tree in as clean as
> possible a way?
> >
> > I don't really know how to respond to this thread.  I feel like I'm
> > being offered the following choice:
> >
> > 1) Give up the ability to have technical input to how WebCore works
> > and simply accept all the design choices made in the iOS fork, whether
> > they be good choices or bad.
> >
> > 2) Keep the iOS port in an Apple-internal fork for a number of years.
> >
> > I feel like I'm being asked to make this choice in the context of a
> > growing trend of unilateral action by Apple in this project.  Given
> > that trend, I don't see how I can choose option (1).
> >
> > As much as I would like the iOS port merged into trunk, I'm not
> > willing to give up having a technical say in the project.  Therefore,
> > reluctantly, I'm forced to choose option (2).
>
> If we'd taken an equally hard line when Google wanted to merge the
> Chromium port to trunk, with a number of design choices in place that we
> didn't agree with but which were hard to change, it probably still wouldn't
> be in the tree to this day. I don't think that would have been a good thing
> for the WebKit project.
>

I think this is a bit different.

For the Chromium port, we started out with the assumption that we couldn't
easily change much about the architecture of WebCore.  Instead, we tried to
make Chromium match the set of constraints imposed on WebCore by WebKit,
CFNetwork, CoreGraphics and more recently CoreAnimation.

This led to things like hiding the details of the out-of-process network
stack behind ResourceHandle.  We did so because we assumed that it would
make our port less of a burden to others.



>
> I am curious how others feel about the value of merging the iOS port back
> to trunk as soon as possible, vs. the need to fix all of the past design
> decisions in this port that may be disputed.
>

I think it is valuable to upstream the iOS port.  I'm sad that it has not
happened sooner.  Many times, the architecture of the iOS port has been
used as justification by Apple engineers for why WebCore should work a
certain way.  It is often not obvious from the open source code that such
constraints exist.  Having the code in the open would seem to help with
such issues.

I would recommend minimizing the re-architecture of WebCore as you are in
the early stages of upstreaming.  It seems like you already have a working
port that you could simply upstream.  You could then work with others in
the community to introduce new concepts to WebCore with the full disclosure
of code as an aide to the process.  Another option might be to open source
the entire thing as a branch somewhere.

After the initial upstreaming or sharing of code is complete, you could
then catalog all of the warts.  The fact that isMainThread returns true
when called on more than one thread would be one such wart.  I can imagine
a meta bug tracking all of these warts.  This would make it a lot easier
for others to understand the overall change in direction needed for WebKit
to properly support the iOS port.

Hope this helps!
-Darin



>
> Regards,
> Maciej
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Merging the iOS port to svn.webkit.org (Re: WebCore and interlocking threads)

[Maciej Stachowiak]

On Feb 8, 2013, at 1:41 PM, Adam Barth  wrote:

> Context: https://bugs.webkit.org/show_bug.cgi?id=109071
> 
> Adam Barth said:
>> It's not clear to me that running WebCore on multiple interlocked threads is 
>> a good idea.  That
>> seems like a pretty major change to WebCore's architecture.  Is that 
>> something that's up for
>> discussion?
> 
> Darin Adler said:
>> I agree that it’s not something I’d do if I was starting a project now.
>> 
>> In the iOS context, it’s fantastic for discussion as a possibly multi-year 
>> major architecture
>> change, but if we take a hard line on this, then we won’t have the iOS port 
>> in the tree for
>> years, and I think it would be good if we do. iOS WebKit has worked this way 
>> for the entire
>> history of iPhone, so it’s not a change that can be made easily.
> 
> Darin Adler also said:
>> I think where you and I may differ is on whether a good solution to the 
>> problem would be
>> valuable to the WebKit project. Is there some way I convince you of the 
>> value of fitting
>> an important existing port of WebKit into our tree in as clean as possible a 
>> way?
> 
> I don't really know how to respond to this thread.  I feel like I'm
> being offered the following choice:
> 
> 1) Give up the ability to have technical input to how WebCore works
> and simply accept all the design choices made in the iOS fork, whether
> they be good choices or bad.
> 
> 2) Keep the iOS port in an Apple-internal fork for a number of years.
> 
> I feel like I'm being asked to make this choice in the context of a
> growing trend of unilateral action by Apple in this project.  Given
> that trend, I don't see how I can choose option (1).
> 
> As much as I would like the iOS port merged into trunk, I'm not
> willing to give up having a technical say in the project.  Therefore,
> reluctantly, I'm forced to choose option (2).

If we'd taken an equally hard line when Google wanted to merge the Chromium 
port to trunk, with a number of design choices in place that we didn't agree 
with but which were hard to change, it probably still wouldn't be in the tree 
to this day. I don't think that would have been a good thing for the WebKit 
project.

I am curious how others feel about the value of merging the iOS port back to 
trunk as soon as possible, vs. the need to fix all of the past design decisions 
in this port that may be disputed.

Regards,
Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev