Re: [webkit-dev] Current status of threaded compositor for WebKit Gtk
Replying from right address this time... On Mon, Apr 15, 2013 at 9:23 AM, Noam Rosenthal n...@webkit.org wrote: Thanks Gwang-Yoon Yes, I would like to get rid of TextureMapperImageBuffer, and we can do that once Qt-WebKit1 can move to the threaded compositor. I would like to use the threaded compositor as a replacement for the direct TextureMapper approach in general, so that we have less unmaintained code paths. What concerns me right now is that this implementation would fragment code paths that we should focus on removing, such as non composited contents ( https://bugs.webkit.org/show_bug.cgi?id=110355). But otherwise let's move forward as far as I'm concerned... On Mon, Apr 15, 2013 at 2:53 AM, Gwang-Yoon Hwang ryum...@company100.netwrote: Thanks for respond. On Mon, Apr 15, 2013 at 1:10 AM, Martin Robinson mrobin...@webkit.orgwrote: On Sun, Apr 14, 2013 at 12:52 AM, Gwang-Yoon Hwang ryum...@company100.net wrote: Nice work! 1. There are 3 accelerated compositing methods in WebKit1 Gtk. Cairo, Clutter, and GL. These patches will adds 1 more options, threaded compositing. I think we need to simplify/unite rendering paths to reduce complexity. I think that No'am expressed interest in ditching the ImageBuffer compositor, so that would simplify things a bit. Good. Let's discuss about that with No'am. 2. In these patches, I attached threaded compositor into webkit1 gtk with untidy codes. (ex ChromeClientGtk, FrameLoaderClientGtk.. ) I think if we need to maintain 4 compositing paths at a time, we need more cleaner approach, with a single interface factory. I'm surprised you didn't focus on WebKit2, since WebKit1 is in maintenance mode now. --Martin It was easier to prototype, debug in WebKit1. So I did it first. Now I am going to make it for WebKit2 Gtk. And, there are another reason for that, If we choose threaded compositor on WK2 only, we need to add another compositing path to our maintenance list. I think it would be better if WK1 and WK2 uses same unify compositing paths to reduce maintenance issues. ___ 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] Current status of threaded compositor for WebKit Gtk
On Sunday 14 April 2013, Martin Robinson wrote: I'm surprised you didn't focus on WebKit2, since WebKit1 is in maintenance mode now. WebKit1 is easier to develop for. Especially now that we are not allowed to develop in WebKit2 anymore.. Second. Part of what this worl gives us is to unify the code-paths that QtWK1 and QtWK2 uses and thereby get rid of WK1 specific codepaths in WK2. I think it is a mistake to keep WK1 so undeveloped that it just ties up code in WebCore we can not remove or clean up. Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Filip Pizlo [fpi...@apple.com] Sent: Saturday, April 13, 2013 12:17 PM To: Ian Hickson Cc: dpra...@chromium.org; Benjamin Poulain; webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types Same difference. I think this is overly harsh. Nobody will hold a gun to your head and force you to use threads. The bumbling fools will probably ignore it. Experience from desktop development tells me that bumbling fools absolutely love threads, and will probably start sticking things that are more appropriately done in other ways into threads as soon as threads are available. Ok, let's use the less-loaded term of unprepared novice: the primary characteristic of this type of developer is that they have a task they want to complete, they Google to find a tool for the job, and then they hack something together with the first tool they find without taking time to study it and learn its intricacies, or evaluate alternatives. Often they follow sample programs without understanding what the samples are doing. Threads are complicated, and really should not be used without a thorough grounding in what can go wrong. Unfortunately there are lots of primers out there that give a very sketchy overview of how to use threads, and novice programmers are exactly the type to take a sketchy overview and think that's all they need to know to start coding. Other approaches are also complicated, yes - we should evaluate each approach to see how complicated each is and how much guidance the structure of the API gives in how to use it correctly, on the assumption that novice programmers WILL be trying to write complex things using nothing more than a random one page blog post about the API for documentation. We can't assume that just because the API is complicated, novices will not find out about it - novices love to play with the new shiny things as much as anybody. The situation we have now is far worse actually: to get your scripts to do useful thing you need to turn them inside-out using continuation passing style. Much of it is because every interesting API is asynchronous. Are you suggesting that continuation passing style with fully asynchronous APIa is easier to understand than threads and synchronous APIs? I suspect that they can both be classified as hard, and both lead to people making terrible mistakes. I also suspect that threads are the easier of the two - at least that is my thinking based on memories of how hard it was for a professor to explain CPS to people. My experience is that threads and locks are roughly equivalent to goto: easy to explain how they work, but because they can be used in so many ways, harder to explain how to use them safely. While continuation passing, or message passing, or event driven styles are more like standard procedural flow control: more restrictive in how you structure your programs (which is the point!) but less conducive to creating spaghetti code. I definitely think that asynchronous API's are much easier to reason about than traditional threads locks, once you grok how asynchronous API's work. With threads locks, even an advanced user has to do a lot of work to prove their design correct every time use of a lock is altered. They're extremely fragile compared to higher-level abstractions. The higher-level abstractions MAY be as difficult to learn (although my anecdotal experience is the opposite) but more of the work is up front in setting up to use them in the first place. Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Layout Tests and the W3C
Hi all, Those of you who are subscribed to blink-dev@ will see that I just sent out a note entitled Blink, Testing and the W3C, describing stuff I'm working on to get the W3C tests running regularly as part of the layout tests. The W3C has gotten to the point where they have many thousands of ref tests, a lot of which are newer versions of old test suites that we imported once upon a time (meaning that we can replace a lot of pixel tests with ref tests). That work leverages a bunch of work Rebecca Hauck has been working on that actually started pre-Blink-fork, and in fact currently only exists as a patch posted to bugs.webkit.org ( https://bugs.webkit.org/show_bug.cgi?id=111513 ). I would like to get something resembling the same process working for both WebKit and Blink, since we use basically the same tools. There will probably be some differences, of course, e.g., in how we mirror repos and track issues, but I would hope we'd all agree the more tests we can share (both between WebKit and Blink and with other vendors like FF and IE) the happier everyone will be, right? We haven't really worked out the processes for how this'll work yet; Rebecca and I were starting to work on it when the fork happened. Assuming there is still interest, I'll start sketching out how things might work for WebKit and report back. Also, if we actually start to make progress on this, I'd be happy to talk about it at the WebKit committer's meeting if there's interest there as well. Thoughts? -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Layout Tests and the W3C
On Apr 15, 2013, at 5:31 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, Those of you who are subscribed to blink-dev@ will see that I just sent out a note entitled Blink, Testing and the W3C, describing stuff I'm working on to get the W3C tests running regularly as part of the layout tests. The W3C has gotten to the point where they have many thousands of ref tests, a lot of which are newer versions of old test suites that we imported once upon a time (meaning that we can replace a lot of pixel tests with ref tests). That work leverages a bunch of work Rebecca Hauck has been working on that actually started pre-Blink-fork, and in fact currently only exists as a patch posted to bugs.webkit.org ( https://bugs.webkit.org/show_bug.cgi?id=111513 ). I would like to get something resembling the same process working for both WebKit and Blink, since we use basically the same tools. There will probably be some differences, of course, e.g., in how we mirror repos and track issues, but I would hope we'd all agree the more tests we can share (both between WebKit and Blink and with other vendors like FF and IE) the happier everyone will be, right? We haven't really worked out the processes for how this'll work yet; Rebecca and I were starting to work on it when the fork happened. Assuming there is still interest, I'll start sketching out how things might work for WebKit and report back. Also, if we actually start to make progress on this, I'd be happy to talk about it at the WebKit committer's meeting if there's interest there as well. I think it would be great to run W3C reftests as part of WebKit's layout tests. Extra awesome would be to have the setup to import new versions of test suites and/or new test suites regularly. I would welcome such work and I expect others would as well. I also think this would make a great contributor's meeting topic, either as a regular session or a hackathon. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
On Apr 12, 2013, at 10:26 PM, Filip Pizlo fpi...@apple.com wrote:
You have all of the same problems as with threads and locks. The two are
logically equivalent. You can imagine a lock as being a message queue that
always has a token in it when the lock is unlocked, and the token is read out
to lock the lock. You can imagine a shared memory location as being a task
that controls that location, and you send messages to it to read and write
the location.
The key difference in practice seems to be that message passing can be made
nonblocking and asynchronous, whereas locking typically is not.
- No possibility of deadlock
There is a possibility of deadlock. You can have one task waiting for a
message from another, and that other waiting for a message from the first.
Yes, you can have pseudo-deadlocks like this, but unlike actually blocking on a
mutex in serial code on the main thread, this will not cause the web page as a
whole to outright hang. This is the only distinction I meant to draw. If my
webpage was blocked on a hypothetical JS mutex on the main thread, then I (as
the user) can't click on a link or select text or what have you. If it's
waiting for a message reply that never comes, then I almost certainly can.
But I think that deadlocks are a red herring. For a locked program to
experience deadlock, you need an inversion of lock nesting. But not only can
this be detected dynamically - you can throw an exception as soon as it
happens - it also seems to happen infrequently. I've seen people scare each
other over them at programming language conferences, but I think that
deadlocks are sufficiently rare in practice that it's not worth worrying too
much about.
I had the (perhaps incorrect) impression that there was no reliable way to
avoid lock inversion other than globally ensuring that the program as a whole
always grabs locks in the same order. If there is a better solution, then fine.
But even a good solution would entail the potential of blocking the WebProcess
main thread for a long time, and message passing doesn't have that effect.
- No performance penalty from correctly supporting fine-grained concurrent
access to arbitrary mutable objects
There is a huge performance penalty. Message queues involve the same
underlying synchronization primitives as locks.
There's no penalty to single-threaded code from message passing, though. With
shared state however: If every JS array had to safely handle concurrent access
from multiple threads (at the very least preventing memory corruption), that
would be a huge performance penalty for single-threaded code. Or if you only
turn on the checks when a second thread is created, then you have a performance
cliff, and the checks would likely still harm code that doesn't actually access
data structures concurrently.
Message passing (at least in the Workers style) is really only suitable for
course-grained concurrency, and indeed, it does impose a significant
communication overhead.
The first is particularly important as you really do not want the web page's
UI thread to lock up, even if the page itself is not making progress.
But message passing also leads to lock-up. You could have someone waiting
for a message that hasn't been sent yet.
I clarified above what I meant here.
Of course you could try to side-step this by mandating that there is no
synchronous message receive operation on the main thread, and instead all
messages arrive back asynchronously.
Indeed, there is no synchronous message receive on any thread in Web Workers.
But there is no reason why you couldn't do that with locks: you could have
an async lock operation:
lock.acquireAsynchronously(function() { … do things once lock is available …
});
Can a lock-based model with only asynchronous locking be made efficient enough
for real use? (If you offer the synchronous version at all, then the worst
programmers will use it, once again leading to blocking). I would guess it ends
up only good enough for course-grained concurrency, at which point it does not
have much advantage compared to message passing.
But I'm not sure that this would even be necessary. If the web page's UI
gets stuck because of an error made by the programmer, then that's not
necessarily the programming language designer's problem to solve.
If a mistake of type X with consequence Y is possible in Model A but not in
Model B, that's an advantage for Model B. The Web has set higher expectations
of protecting the user from the consequences of badly written webpages.
I don't believe that a deadlock is any more likely than a long-running
computation or a run-away memory leak. In fact in my experience it is less
likely, particularly if you provide people with a sensible API for good
locking discipline like:
lock.acquire(function() { … do things … });
And specifically disallow manual lock
Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Maciej Stachowiak [m...@apple.com] Sent: Monday, April 15, 2013 10:05 PM To: Filip Pizlo Cc: Benjamin Poulain; webkit-dev@lists.webkit.org; dpra...@chromium.org Subject: Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types These languages are popular, but I believe most complex projects using them with threading a long tail of nasty but hard-to-diagnose threadsafety bugs. Indeed, my assumption was always that languages with special-purpose concurrency constructs were not popular for the same reason all special-purpose languages are not popular compared to C++: they're not C++. It's hard to get over the hump of competing with C++, and a new concurrency paradigm isn't enough to do it even if that paradigm is better than shared memory+mutexes. The lack of success isn't evidence that the concurrency construct is worthless, just that lacks whatever spark (which is often marketing and not technical superiority) that causes some languages to succeed and others to fail. Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
