Re: [webkit-dev] Increasing the number of cross-platform/port expected results
Mozilla has been using this technique for years. Perhaps we can pick their brains for some good tricks. Or, dare I say it, share some tests. Hi, hope I'm not crashing the party, and sorry I'm late :-). Let me just say a few things about reftests... Maciej mentioned that a reftest can assert that b and style=font-weight:bold are equivalent, but would not catch a bug that completely disabled font-weight. That is true. However, in our reftest framework you can also assert that two pages render differently, so you can test that font-weight:normal renders differently from font-weight:bold, which would catch a bug like that. If you look in the Mozilla reftests, there are many tests with 'sanity' in the name ensuring that pages that should render differently, do. You could still miss a weird bug like font-weight:bold making the text italic instead. But in practice, we hardly ever encounter bugs that cause some reftests to render incorrectly and still all tests pass. Over time we have learned a number of tricks for writing reftests. Here are a few: -- In general we require tests to match pixel-perfectly. It's always tempting to allow a fudge factor, but tiny differences can indicate significant bugs. -- We have nifty SVG filter tricks to help find those tiny differences, e.g. http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/reftest-analyzer.xhtml -- If some pixels of a test are unpredictable or platform-dependent, but not relevant to the test, you can censor them out by placing an opaque element over them in the test and reference. -- In other tests with unpredictable pixel values, e.g. video, we use SVG filters to threshold pixel channel values. -- The Web usually has More Than One Way To Do It. E.g. for CSS gradients, a lot of our reference pages use canvas to render a reference gradient. -- Many Web features have particular cases that are easy to reduce to reftests even when general cases aren't. For example, box-shadow and text-shadow with no blur are trivial to test with reftests. You can create gradients using repeated stops to achieve abrupt transitions and test them against colored boxes. You could use a similar trick to test patterns in SVG text. -- Aggressive subpixel antialiasing is a real pain. For example, wrapping text in an overflow:hidden container isn't always a no-op even if the container is sized to its contents. Using sans-serif fonts helps, using CSS padding helps more. -- For speed, conciseness and overall expediency, you can often pack many variations of a test into a single reftest page, and in practice there's no significant downside to that. One might argue that although reftests are a good way to test what they test, they don't provide enough broad functional testing, e.g. to make sure that blurs look right. I don't have good data to refute or confirm that. However, if we want to, we can get an image test just by making the reference page a PNG ... but I can only see two cases out of over 4000 where we felt we needed to do that. Overall, I'm extremely enthusiastic about reftests! As others mentioned, we'd like to get official CSS and SVG test suites using reftests; they're the best approach I know of for writing robust automated layout and rendering tests across platforms and browsers. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] CookieJar needs client interface?
Hi all, I am currently implementing the cookie jar backend for the Haiku port and browser. Looking at the other implementations, most of them do it in their network platform code, many are still incomplete. Isn't handling of cookies something browser specific? Looking at the Qt port, it seems like a drastic layering violation, using classes from WebKit in WebCore. So I was wondering if this shouldn't be implemented in a similar pattern to other client interfaces. With a CookieJarClient which has to be implemented in WebKit support code, thus allowing a WebKit client specific change of behavior with a clean separation of layers. Is this a good line of thought and is there any interest in something like this? I have set up build environments for the GTK port, Haiku of course and I could also get the Qt port compiling. So that I could try to provide implementations for at least these platforms. Another approach could be to provide the implementation for Haiku only, so that other ports could adopt this scheme if and when they want. Assuming of course that this change is at all desirable. Best regards, -Stephan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKitGTK+ on Snow Leopard
Has someone actually been able to compile WebKitGTK+ on Snow Leopard? I have retrieved all the dependancies via Mac ports and fink and always seem to get hung up on libjpeg where the compiles believes the library is missing when it is not. Cheers, Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Objective-C Plug-in for Linux
From: http://developer.apple.com/mac/library/documentation/InternetWeb/Conceptual/WebKit_PluginProgTopic/Concepts/AboutPlugins.html#//apple_ref/doc/uid/30001248-BAJGJJAH It states that Although the API is not cross-platform, any plug-in created in this fashion can be used in Safari and all other WebKit-based applications. This statement seems contradictory as you can write WebKit-based application on non-OS X machines. So can you write an Objective-C based plugin that runs on Linux assuming you don't use any OS-X specific frameworks such as Cocoa and Carbon? Thanks in advance, Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CookieJar needs client interface?
Implementing cookies is surprisingly subtle, mostly because the protocol is quite brittle. If you're implementing your own cookie store, a decent starting point might be to look at: http://src.chromium.org/viewvc/chrome/trunk/src/net/base/cookie_monster.cc?view=markup http://tools.ietf.org/html/draft-ietf-httpstate-cookie Note that the licensing of cookie_monster is a bit complicated because it's based on Mozilla's implementation and so carries Mozilla's usual tri-license. The spec is a work in progress, but fairly complete at this time. I'm not sure whether we want to have a cookie implementation in WebKit proper. By and large, we try to use operating system libraries whenever possible. If we did, we'd want to think carefully about the interface so that it could be used by the network stack directly (i.e., for network requests that didn't originate within WebKit). Adam On Tue, Mar 9, 2010 at 1:19 AM, Stephan Assmus supersti...@gmx.de wrote: Hi all, I am currently implementing the cookie jar backend for the Haiku port and browser. Looking at the other implementations, most of them do it in their network platform code, many are still incomplete. Isn't handling of cookies something browser specific? Looking at the Qt port, it seems like a drastic layering violation, using classes from WebKit in WebCore. So I was wondering if this shouldn't be implemented in a similar pattern to other client interfaces. With a CookieJarClient which has to be implemented in WebKit support code, thus allowing a WebKit client specific change of behavior with a clean separation of layers. Is this a good line of thought and is there any interest in something like this? I have set up build environments for the GTK port, Haiku of course and I could also get the Qt port compiling. So that I could try to provide implementations for at least these platforms. Another approach could be to provide the implementation for Haiku only, so that other ports could adopt this scheme if and when they want. Assuming of course that this change is at all desirable. Best regards, -Stephan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Increasing the number of cross-platform/port expected results
On Tue, Mar 9, 2010 at 9:19 AM, Robert O'Callahan rob...@ocallahan.orgwrote: Mozilla has been using this technique for years. Perhaps we can pick their brains for some good tricks. Or, dare I say it, share some tests. Hi, hope I'm not crashing the party, and sorry I'm late :-). Let me just say a few things about reftests... Maciej mentioned that a reftest can assert that b and style=font-weight:bold are equivalent, but would not catch a bug that completely disabled font-weight. That is true. However, in our reftest framework you can also assert that two pages render differently, so you can test that font-weight:normal renders differently from font-weight:bold, which would catch a bug like that. If you look in the Mozilla reftests, there are many tests with 'sanity' in the name ensuring that pages that should render differently, do. You could still miss a weird bug like font-weight:bold making the text italic instead. But in practice, we hardly ever encounter bugs that cause some reftests to render incorrectly and still all tests pass. Over time we have learned a number of tricks for writing reftests. Here are a few: -- In general we require tests to match pixel-perfectly. It's always tempting to allow a fudge factor, but tiny differences can indicate significant bugs. -- We have nifty SVG filter tricks to help find those tiny differences, e.g. http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/reftest-analyzer.xhtml -- If some pixels of a test are unpredictable or platform-dependent, but not relevant to the test, you can censor them out by placing an opaque element over them in the test and reference. This and several of the other tips in here seem like they can apply nicely to our existing layout tests as well. -- In other tests with unpredictable pixel values, e.g. video, we use SVG filters to threshold pixel channel values. -- The Web usually has More Than One Way To Do It. E.g. for CSS gradients, a lot of our reference pages use canvas to render a reference gradient. -- Many Web features have particular cases that are easy to reduce to reftests even when general cases aren't. For example, box-shadow and text-shadow with no blur are trivial to test with reftests. You can create gradients using repeated stops to achieve abrupt transitions and test them against colored boxes. You could use a similar trick to test patterns in SVG text. -- Aggressive subpixel antialiasing is a real pain. For example, wrapping text in an overflow:hidden container isn't always a no-op even if the container is sized to its contents. Using sans-serif fonts helps, using CSS padding helps more. -- For speed, conciseness and overall expediency, you can often pack many variations of a test into a single reftest page, and in practice there's no significant downside to that. One might argue that although reftests are a good way to test what they test, they don't provide enough broad functional testing, e.g. to make sure that blurs look right. I don't have good data to refute or confirm that. However, if we want to, we can get an image test just by making the reference page a PNG ... but I can only see two cases out of over 4000 where we felt we needed to do that. Overall, I'm extremely enthusiastic about reftests! As others mentioned, we'd like to get official CSS and SVG test suites using reftests; they're the best approach I know of for writing robust automated layout and rendering tests across platforms and browsers. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Objective-C Plug-in for Linux
Sorry for the dumb question. i found my answer further below in the What Kind Of Plug-in Should I Develop?. On Tue, Mar 9, 2010 at 4:55 AM, Christopher White skullkn...@gmail.comwrote: From: http://developer.apple.com/mac/library/documentation/InternetWeb/Conceptual/WebKit_PluginProgTopic/Concepts/AboutPlugins.html#//apple_ref/doc/uid/30001248-BAJGJJAH It states that Although the API is not cross-platform, any plug-in created in this fashion can be used in Safari and all other WebKit-based applications. This statement seems contradictory as you can write WebKit-based application on non-OS X machines. So can you write an Objective-C based plugin that runs on Linux assuming you don't use any OS-X specific frameworks such as Cocoa and Carbon? Thanks in advance, Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and the V8 debugger protocol
Hi Jonathan, I've been working on remote debugging/profiling of webkit and I've been leveraging work that the webkit and chromium guys did to separate the Web Inspector frontend from backend. I was actually thinking about sending email to the list this morning about agreeing on a remote/on-device protocol for debugging and profiling webkit. It is possible to replace the javascript in the Web Inspector front-end in order to enable a remote connection to the Web Inspector backend. Once you do that, you can remotely debug, inspect, and profile your code. I have made two prototypes enable remote debugging. In these two prototypes, I have used the Web Inspector UI running in Safari or WebKit on a desktop connected to the backend running in a webkit instance on another device. My first prototype was all implemented in C++ for qtwebkit. There is a patch with this code: Qt debug agent partially implementing ChromeDevTools and V8 debug protocolhttps://bugs.webkit.org/attachment.cgi?id=48913 attached to https://bugs.webkit.org/show_bug.cgi?id=35016 Given the feedback on that set of patches, I've been working on a javascript debug agent with this patch to load alternate inspector javascript: https://bugs.webkit.org/show_bug.cgi?id=35340 I also did a partial implementation of the ChromeDevTools protocol and a V8Debug protocol adapter for JavaScriptCore. In discussions with some of the Chromium guys, it sounds like they would like to move ChromeDevTools protocol closer to the internal protocol used by WebKit. I would like to see a stable inspection/profiling/debug protocol for WebKit and JavaScriptCore. Best regards, Jamey Hicks On Mar 8, 2010, at 7:18 PM, ext Fischoff, Jonathan wrote: I would like to control JavaScript execution in my app remotely using the V8 debugger protocol. Does anyone know if there exists code that implements and the V8 debugger protocol for JavaScriptCore? My main goal is remotely debug JavaScript, so I am also wondering what other technologies exist for remotely debugging JavaScriptCore. Any ideas? -Jonathan Fischoff ATT1..txt ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CookieJar needs client interface?
From: aba...@webkit.org Date: Tue, 9 Mar 2010 06:54:32 -0800 To: supersti...@gmx.de CC: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] CookieJar needs client interface? Implementing cookies is surprisingly subtle, mostly because the protocol is quite brittle. If you're implementing your own cookie store, a decent starting point might be to look at: http://src.chromium.org/viewvc/chrome/trunk/src/net/base/cookie_monster.cc?view=markup http://tools.ietf.org/html/draft-ietf-httpstate-cookie Note that the licensing of cookie_monster is a bit complicated because it's based on Mozilla's implementation and so carries Mozilla's usual tri-license. The spec is a work in progress, but fairly complete at this time. I wrote one from scratch but tried to document sources of wisdom such as any standards used or this is what wget/curl left in their cookie files or this dosn't work on foo etc. I'm glad someone else thinks this is subtle. The ietf doc you cite is only a few months old and claims to obsolete rfc2109 but that claims to be obsoleted by http://tools.ietf.org/html/rfc2965 which I apparently used as a guide. ) . Is there a list of Standard Bugs (probably IE LOL) that are often emulated? Just looking at comments in your code link, some of those browser issues sound familiar - we were getting sites sending the same oookie header 50 times and putting in spaces or other things in odd places. ( Also, I thought I was clever for calling it a cookie monster too LOL). In our case, with a limited resource target platform ( phones) we should have devoted more attention to management- not just deleting old stuff but generally setting some limits and having a removal policy. I guess another thing I've seen come up is general issues with data structs for headers. Hashtables seem to be popular now and don't support duplicate headers, such as multiple cookie's, so you need to concatenate all the dups. I think originally our cookie handler had a problem with this as it expected each cookie in a sep header but probably it was because I hadn't originally coded it rater than inherent problems with spec or implementation by servers( spending hours hitting my own code stub is really annoying LOL). I also seem to recall there may have been an issue with cookies set from non-200 responses but again I think that was just a code bug, not a subtly. I'm not sure whether we want to have a cookie implementation in WebKit proper. By and large, we try to use operating system libraries whenever possible. If we did, we'd want to think carefully about the interface so that it could be used by the network stack directly (i.e., for network requests that didn't originate within WebKit). Adam On Tue, Mar 9, 2010 at 1:19 AM, Stephan Assmus wrote: Hi all, I am currently implementing the cookie jar backend for the Haiku port and browser. Looking at the other implementations, most of them do it in their network platform code, many are still incomplete. Isn't handling of cookies something browser specific? Looking at the Qt port, it seems like a drastic layering violation, using classes from WebKit in WebCore. So I was wondering if this shouldn't be implemented in a similar pattern to other client interfaces. With a CookieJarClient which has to be implemented in WebKit support code, thus allowing a WebKit client specific change of behavior with a clean separation of layers. Is this a good line of thought and is there any interest in something like this? I have set up build environments for the GTK port, Haiku of course and I could also get the Qt port compiling. So that I could try to provide implementations for at least these platforms. Another approach could be to provide the implementation for Haiku only, so that other ports could adopt this scheme if and when they want. Assuming of course that this change is at all desirable. Best regards, -Stephan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/201469229/direct/01/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] CookieJar needs client interface?
On Tue, Mar 9, 2010 at 8:21 AM, Mike Marchywka marchy...@hotmail.com wrote: I wrote one from scratch but tried to document sources of wisdom such as any standards used or this is what wget/curl left in their cookie files or this dosn't work on foo etc. I'm glad someone else thinks this is subtle. That is the historical technique for writing a cookie implementation. Unfortunately, that leads to subtle interoperability problems. I would encourage you to implement http://tools.ietf.org/html/draft-ietf-httpstate-cookie exactly as specified. A number of people have put significant effort into that document so that if you follow it's requirements your cookie implementation should actually work. The ietf doc you cite is only a few months old and claims to obsolete rfc2109 but that claims to be obsoleted by http://tools.ietf.org/html/rfc2965 which I apparently used as a guide. ) . You'll be better off if you pretend rfc2109 and rfc2965 don't exist. I suspect they're doing more harm to your implementation than good. Is there a list of Standard Bugs (probably IE LOL) that are often emulated? http://tools.ietf.org/html/draft-ietf-httpstate-cookie document what I and the cookie working group at the IETF currently believe are the best trade-offs with respect to implementing the cookie protocol today. Just looking at comments in your code link, some of those browser issues sound familiar - we were getting sites sending the same oookie header 50 times and putting in spaces or other things in odd places. That code is very close to the requirements in http://tools.ietf.org/html/draft-ietf-httpstate-cookie, as are the Firefox and IE implementations. Curl is far from correct and, IMHO, not a good model to work from. ( Also, I thought I was clever for calling it a cookie monster too LOL). In our case, with a limited resource target platform ( phones) we should have devoted more attention to management- not just deleting old stuff but generally setting some limits and having a removal policy. I guess another thing I've seen come up is general issues with data structs for headers. Hashtables seem to be popular now and don't support duplicate headers, such as multiple cookie's, so you need to concatenate all the dups. I think originally our cookie handler had a problem with this as it expected each cookie in a sep header but probably it was because I hadn't originally coded it rater than inherent problems with spec or implementation by servers( spending hours hitting my own code stub is really annoying LOL). You'll need to be able to represent duplicate HTTP headers to process HTTP responses correctly. I also seem to recall there may have been an issue with cookies set from non-200 responses but again I think that was just a code bug, not a subtly. I'm not aware of this issue, but I'd be interested to learn more if you have more details. By the way, there's also a test suite available for the cookie protocol, which you can find out more about here: http://github.com/abarth/http-state/tree/master/tests/ Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
Yeah, it's a race condition - it seems to all depend on whether the worker resource gets loaded before the postMessage loop starts. Failure rate is around 30-50% on my machine. It looks like events have priority in Cocoa, and I'm guessing that performSelectorOnMainThread() creates events with a higher priority than those generated by URLConnection, which can lead to starvation. I'm not certain what the right fix is, other than to maybe use a different method of dispatching events other than performSelectorOnMainThread that lets us set a lower priority? -atw On Mon, Mar 8, 2010 at 7:24 PM, Dmitry Titov dim...@chromium.org wrote: At least user input is dispatched even if there are outstanding performSelectorOnMainThread calls: https://bugs.webkit.org/show_bug.cgi?id=23705 With the change in postTask, the cloneport test does not always hang - on my machine it's 50-50. There is some racing condition somewhere perhaps... On Mon, Mar 8, 2010 at 5:29 PM, Drew Wilson atwil...@google.com wrote: Following up with a related note - does anyone have any insight into how the Cocoa event loop dispatches events from different sources? In particular, I have a test (worker-cloneport.html) which posts a port back and forth between two endpoints (both on the main thread). With the change to Document.postTask() I described earlier in this thread, this test results in there always being a pending event (posted via performSelectorOnMainThread) when we re-enter the cocoa runloop. It appears that the run loop *always* dispatches this event before dispatching events from NSURLConnection - the result is that any pending resource loads never complete. Is there some kind of prioritization within the cocoa run loop so that certain types of events (like NSURLConnection events) if there are no pending events of other types? -atw On Mon, Mar 8, 2010 at 2:08 PM, Dmitry Titov dim...@chromium.org wrote: Many tasks are just fine to execute while modal UI is present. For example, XHR in a Worker probably should not be frozen by an alert on the parent page. That posts tasks to main thread for loader. Also, it's unclear if a task can be simply delayed or in fact some other action should be performed at resume point - for example, timers re-calculate the next fire time. Maybe there can be a generic mechanism for tasks to participate in suspend/resume... It'd require a better definition of the events - for example, is there a difference between suspense on modal UI and suspense on going into BF cache? Probably there is. Dmitrty On Mon, Mar 8, 2010 at 1:45 PM, Drew Wilson atwil...@google.com wrote: So the implication is that every single place that uses tasks has to have an associated activeDOMObject() or other hooks in ScriptExecutionContext so it can get suspend/resume calls and try to queue up the tasks for later? That seems a) hard (since not everything that uses tasks necessarily has an activeDOMObject), and b) fragile because we'll undoubtedly miss cases -- there's something like 70 calls to callOnMainThread()/postTask() in the WebCore code. Is there no way to do something at a lower level? callOnMainThread() already keeps a queue of pending callbacks, so it seems like just not dispatching those callbacks might be better? It's tricky because you don't necessarily know which ScriptExecutionContext a task is destined for at that low level. -atw On Mon, Mar 8, 2010 at 1:24 PM, Dmitry Titov dim...@chromium.orgwrote: On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov a...@webkit.orgwrote: On 08.03.2010, at 11:21, Drew Wilson wrote: So, my question is: does it surprise anyone that tasks posted via callOnMainThread() are getting executed even though there's a modal dialog shown? And is there anything I should be doing in my task handler to make sure we aren't re-entering JS execution inappropriately in these cases? I'm just concerned that the way we're posting tasks from worker threads to the main thread may cause reentrancy problems. It is not correct to deliver messages from worker threads when an alert or a modal window is displayed. It may be ok for modal dialogs that are triggered asynchronously (such as credentials dialog). We have a manual test regression for a related issue, WebCore/manual-tests/js-timers-beneath-modal-dialog.html. You can compare how timers work, and how worker messages are delivered to find out how to fix the problem. Timers are suspended by ScriptExecutionContext::suspendActiveDOMObjects/resumeActiveDOMObjects from PageGroupLoadDeferrer. So the context (Document) knows when it is suspended and when it gets resumed. It seems the task to process accumulated port messages can be postponed until resume. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
Another alternative is for us to add a flag to
scheduleDispatchFunctionsOnMainThread() which is passed as true in the case
where we are calling it from dispatchFunctionsOnMainThread():
// If we are running accumulated functions for too long so UI may
become unresponsive, we need to
// yield so the user input can be processed. Otherwise user may not
be able to even close the window.
// This code has effect only in case the
scheduleDispatchFunctionsOnMainThread() is implemented in a way that
// allows input events to be processed before we are back here.
if (currentTime() - startTime maxRunLoopSuspensionTime) {
scheduleDispatchFunctionsOnMainThread(true); // delay = true
break;
}
}
That way, in the case where we are in some kind of tight loop and we want to
yield anyway to let UI events happen, we could instead yield for (say) 10ms
to make sure lower priority events have a chance to be dispatched.
Alexey, what do you think? My preference would be to use a lower priority
event instead of a delay, but I don't know enough about Cocoa programming to
know whether that's possible.
-atw
On Tue, Mar 9, 2010 at 9:45 AM, Drew Wilson atwil...@google.com wrote:
Yeah, it's a race condition - it seems to all depend on whether the worker
resource gets loaded before the postMessage loop starts. Failure rate is
around 30-50% on my machine.
It looks like events have priority in Cocoa, and I'm guessing that
performSelectorOnMainThread() creates events with a higher priority than
those generated by URLConnection, which can lead to starvation. I'm not
certain what the right fix is, other than to maybe use a different method of
dispatching events other than performSelectorOnMainThread that lets us set a
lower priority?
-atw
On Mon, Mar 8, 2010 at 7:24 PM, Dmitry Titov dim...@chromium.org wrote:
At least user input is dispatched even if there are outstanding
performSelectorOnMainThread calls:
https://bugs.webkit.org/show_bug.cgi?id=23705
With the change in postTask, the cloneport test does not always hang - on
my machine it's 50-50. There is some racing condition somewhere perhaps...
On Mon, Mar 8, 2010 at 5:29 PM, Drew Wilson atwil...@google.com wrote:
Following up with a related note - does anyone have any insight into how
the Cocoa event loop dispatches events from different sources? In
particular, I have a test (worker-cloneport.html) which posts a port back
and forth between two endpoints (both on the main thread).
With the change to Document.postTask() I described earlier in this
thread, this test results in there always being a pending event (posted via
performSelectorOnMainThread) when we re-enter the cocoa runloop. It appears
that the run loop *always* dispatches this event before dispatching events
from NSURLConnection - the result is that any pending resource loads never
complete.
Is there some kind of prioritization within the cocoa run loop so that
certain types of events (like NSURLConnection events) if there are no
pending events of other types?
-atw
On Mon, Mar 8, 2010 at 2:08 PM, Dmitry Titov dim...@chromium.orgwrote:
Many tasks are just fine to execute while modal UI is present. For
example, XHR in a Worker probably should not be frozen by an alert on the
parent page. That posts tasks to main thread for loader.
Also, it's unclear if a task can be simply delayed or in fact some other
action should be performed at resume point - for example, timers
re-calculate the next fire time.
Maybe there can be a generic mechanism for tasks to participate in
suspend/resume... It'd require a better definition of the events - for
example, is there a difference between suspense on modal UI and suspense
on going into BF cache? Probably there is.
Dmitrty
On Mon, Mar 8, 2010 at 1:45 PM, Drew Wilson atwil...@google.comwrote:
So the implication is that every single place that uses tasks has to
have an associated activeDOMObject() or other hooks in
ScriptExecutionContext so it can get suspend/resume calls and try to queue
up the tasks for later? That seems a) hard (since not everything that uses
tasks necessarily has an activeDOMObject), and b) fragile because we'll
undoubtedly miss cases -- there's something like 70 calls to
callOnMainThread()/postTask() in the WebCore code.
Is there no way to do something at a lower level? callOnMainThread()
already keeps a queue of pending callbacks, so it seems like just not
dispatching those callbacks might be better? It's tricky because you don't
necessarily know which ScriptExecutionContext a task is destined for at
that
low level.
-atw
On Mon, Mar 8, 2010 at 1:24 PM, Dmitry Titov dim...@chromium.orgwrote:
On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov
a...@webkit.orgwrote:
On 08.03.2010, at 11:21, Drew Wilson wrote:
So, my question is: does it surprise anyone that tasks posted via
callOnMainThread() are getting
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
On 09.03.2010, at 9:45, Drew Wilson wrote: Yeah, it's a race condition - it seems to all depend on whether the worker resource gets loaded before the postMessage loop starts. Failure rate is around 30-50% on my machine. It would help to have a more detailed description of the problem. I've been following the discussion in bugs and in this thread, but I'm still unsure about some aspects of it. Seems that there are two issues at hand: 1) We feel the need to change how Document::postTask() behaves, because otherwise, the patch for https://bugs.webkit.org/show_bug.cgi?id=34726 doesn't work. We feel the need because it makes little sense for it to have drastically different behavior depending on what thread it's called from. It feels like a good change to make indeed, but I'm surprised that it apparently went through review unmentioned and unquestioned. The questions to ask are why exactly it was needed, and whether there are other ways to fix bug 34726. 2) if we make that change, the worker-cloneport.html test starts to fail. I didn't attempt to debug this myself, and I don't quite understand the problem description. I see only one postMessage loop in the test, and it's in worker code. How can it be executed before the worker resource gets loaded? It looks like events have priority in Cocoa, and I'm guessing that performSelectorOnMainThread() creates events with a higher priority than those generated by URLConnection, which can lead to starvation. I'm not certain what the right fix is, other than to maybe use a different method of dispatching events other than performSelectorOnMainThread that lets us set a lower priority? These main thread calls do not use events for processing. CF/NSRunLoop has a concept of run loop sources, which can generate events or perform other actions, see http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFRunLoopRef/Reference/reference.html and http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopSourceRef/Reference/reference.html . - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.org wrote: On 09.03.2010, at 9:45, Drew Wilson wrote: Yeah, it's a race condition - it seems to all depend on whether the worker resource gets loaded before the postMessage loop starts. Failure rate is around 30-50% on my machine. It would help to have a more detailed description of the problem. I've been following the discussion in bugs and in this thread, but I'm still unsure about some aspects of it. Seems that there are two issues at hand: 1) We feel the need to change how Document::postTask() behaves, because otherwise, the patch for https://bugs.webkit.org/show_bug.cgi?id=34726 doesn't work. We feel the need because it makes little sense for it to have drastically different behavior depending on what thread it's called from. It feels like a good change to make indeed, but I'm surprised that it apparently went through review unmentioned and unquestioned. The questions to ask are why exactly it was needed, and whether there are other ways to fix bug 34726. This was discussed somewhat off list between dumi, dimich, and myself (and whomever else dumi traded notes with). We were very surprised that tasks scheduled via postTask() were not executed in the same order as being scheduled. This change to postTask() was a shot at remedying that... but low and behold, something was apparently depending on the out of order execution? 2) if we make that change, the worker-cloneport.html test starts to fail. I didn't attempt to debug this myself, and I don't quite understand the problem description. I see only one postMessage loop in the test, and it's in worker code. How can it be executed before the worker resource gets loaded? It looks like events have priority in Cocoa, and I'm guessing that performSelectorOnMainThread() creates events with a higher priority than those generated by URLConnection, which can lead to starvation. I'm not certain what the right fix is, other than to maybe use a different method of dispatching events other than performSelectorOnMainThread that lets us set a lower priority? These main thread calls do not use events for processing. CF/NSRunLoop has a concept of run loop sources, which can generate events or perform other actions, see http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFRunLoopRef/Reference/reference.html and http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopSourceRef/Reference/reference.html . - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.org wrote: On 09.03.2010, at 9:45, Drew Wilson wrote: Yeah, it's a race condition - it seems to all depend on whether the worker resource gets loaded before the postMessage loop starts. Failure rate is around 30-50% on my machine. It would help to have a more detailed description of the problem. I've been following the discussion in bugs and in this thread, but I'm still unsure about some aspects of it. Seems that there are two issues at hand: 1) We feel the need to change how Document::postTask() behaves, because otherwise, the patch for https://bugs.webkit.org/show_bug.cgi?id=34726 doesn't work. We feel the need because it makes little sense for it to have drastically different behavior depending on what thread it's called from. It feels like a good change to make indeed, but I'm surprised that it apparently went through review unmentioned and unquestioned. The questions to ask are why exactly it was needed, and whether there are other ways to fix bug 34726. 2) if we make that change, the worker-cloneport.html test starts to fail. I didn't attempt to debug this myself, and I don't quite understand the problem description. I see only one postMessage loop in the test, and it's in worker code. How can it be executed before the worker resource gets loaded? There is a MessageChannel which sets the same onmessage handler for both ports, and that handler 'reflects' the received message to the sender through the channel. Then the test starts this ping-pong by sending a single message through. As a result, there is always a message in transit - they are delivered via Document::postTask. So at every moment there is at least one task in the postTask's queue, and executing that task immediately adds a new task (since the onmessage handler posts the next message through the MessageChannel). All this ping-pong happens on main thread, while worker gets loaded. That means we always exit the loop processing the tasks in dispatchFunctionsFromMainThread() via timeout, and there are always a performSelectorOnMainThread in the RunLoop queue. The interesting thing I don't yet understand is why one-shot timer (implemented via CFRunLoopAddTimer), when used for queueing in Docuemnt::postTask works fine and performSelectorOnMainThread causes hang of the test. It looks like events have priority in Cocoa, and I'm guessing that performSelectorOnMainThread() creates events with a higher priority than those generated by URLConnection, which can lead to starvation. I'm not certain what the right fix is, other than to maybe use a different method of dispatching events other than performSelectorOnMainThread that lets us set a lower priority? These main thread calls do not use events for processing. CF/NSRunLoop has a concept of run loop sources, which can generate events or perform other actions, see http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFRunLoopRef/Reference/reference.html and http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopSourceRef/Reference/reference.html . - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Why I'm reviewing patches outside my area (and why you should too)
Over the past 24 hours, I've been aggressively reviewing patches in pending-review http://webkit.org/pending-review that have been sitting around for over a month. My approach as been to review the patches in order from oldest to newest with a the buck stops here perspective. That means I'm going to either r+ or r- the patch, even if that means I have to spend several hours learning the related code. As of this morning, I've cleared out all the patches that have been waiting for review for over a month. Q: Why are you doing this? You should stick to reviewing code in your own area. A: The pending-review queue is out of control. It's past the tipping point where there are too many patches for someone to reasonably look at the queue. It's not healthy for the project to leave patches unreviewed for over a month. Someone needs to step up. If not me, then who? Q: Those ancient patches are junk. Why not focus on the newer patches, which are higher quality and from more established contributors? A: Some of the ancient patches are junk, and I've been liberally r-ing them with explanations, but a lot of them are actually quite good. For example, there was a patch that fixed a NULL pointer dereference that affected every port. There was another patch that added a test to an earlier version that was r+ed. If we let patches like these linger for a month, we're discouraging people from fixing crashes and writing tests. Q: What if you break things? A: We can't be afraid of breaking things. That will only paralyze the project. Instead, we should be happy when things break because it shows us where we need more test coverage. Q: Why are you reviewing editing patches, in particular? You don't know anything about editing. A: For whatever reason, the folks who usually review editing patches appear to be MIA. That means we need to grow more editing expertise. Personally, I have about zero interest in editing, but until Ojan is a reviewer, someone needs to do it. If you'd rather review editing patches instead of me, please let me know and I'll happily forward the reviews to you. Q: What are the common reasons patches get stuck in pending-review and who can we fix that? A: Anecdotally, I've been seeing three main causes of patches getting stuck: (1) The patch needs to be reviewed by David Hyatt. David Hyatt appears to be a bottleneck in the project because he's an expert on a number of components that no one else understands as well but he doesn't spend as much time reviewing patches as Maciej or Darin. I think the best solution here is to have more folks gain expertise in these areas. (2) The patch is for a port with fewer reviewers. Reviews for ports like BREW tend to collect in pending-review because there aren't that many reviewers who are personally incentivized to review those patches. As those ports mature, this problem should resolve itself naturally. I've tried to help here where possible, but these patches are the most difficult for me to review. (3) Someone reviewed an earlier version of the patch but then didn't follow up. I think having a partial review by one person encourages other people to assume that person will finish the review. That cause the patch to float upwards in pending-review until it gets lost in the sea of ancient patches. I'd encourage reviewers to follow through with their reviews. Q: How long is this project taking you? A: It seems to be taking me about an average of 45 minutes per patch. That includes the time to read the entire bugzilla thread, review the code, and read up on related areas of the code. If you do the math, you'll see that I won't be able to do this alone. That's why I'm asking for your help. If you're a reviewer, I'd encourage you to work through pending-review from oldest to newest. Don't be afraid of r-ing a patch. Believe me, folks are thankful for feedback (even negative feedback) when their patches have been sitting around collecting dust. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
On 09.03.2010, at 11:23, Michael Nordman wrote: 1) We feel the need to change how Document::postTask() behaves, because otherwise, the patch for https://bugs.webkit.org/show_bug.cgi?id=34726 doesn't work. We feel the need because it makes little sense for it to have drastically different behavior depending on what thread it's called from. It feels like a good change to make indeed, but I'm surprised that it apparently went through review unmentioned and unquestioned. The questions to ask are why exactly it was needed, and whether there are other ways to fix bug 34726. This was discussed somewhat off list between dumi, dimich, and myself (and whomever else dumi traded notes with). We were very surprised that tasks scheduled via postTask() were not executed in the same order as being scheduled. Another way to fix just this aspect would be to piggy-back on existing task queue if it's non-empty, similar to what callOnMainThread() does. I'm not suggesting this, of course, as it still leaves us with a huge risk of race conditions and unexpected behaviors. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
On Tue, Mar 9, 2010 at 11:34 AM, Dmitry Titov dim...@chromium.org wrote: On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.orgwrote: On 09.03.2010, at 9:45, Drew Wilson wrote: Yeah, it's a race condition - it seems to all depend on whether the worker resource gets loaded before the postMessage loop starts. Failure rate is around 30-50% on my machine. It would help to have a more detailed description of the problem. I've been following the discussion in bugs and in this thread, but I'm still unsure about some aspects of it. Seems that there are two issues at hand: 1) We feel the need to change how Document::postTask() behaves, because otherwise, the patch for https://bugs.webkit.org/show_bug.cgi?id=34726 doesn't work. We feel the need because it makes little sense for it to have drastically different behavior depending on what thread it's called from. It feels like a good change to make indeed, but I'm surprised that it apparently went through review unmentioned and unquestioned. The questions to ask are why exactly it was needed, and whether there are other ways to fix bug 34726. 2) if we make that change, the worker-cloneport.html test starts to fail. I didn't attempt to debug this myself, and I don't quite understand the problem description. I see only one postMessage loop in the test, and it's in worker code. How can it be executed before the worker resource gets loaded? There is a MessageChannel which sets the same onmessage handler for both ports, and that handler 'reflects' the received message to the sender through the channel. Then the test starts this ping-pong by sending a single message through. As a result, there is always a message in transit - they are delivered via Document::postTask. So at every moment there is at least one task in the postTask's queue, and executing that task immediately adds a new task (since the onmessage handler posts the next message through the MessageChannel). All this ping-pong happens on main thread, while worker gets loaded. That means we always exit the loop processing the tasks in dispatchFunctionsFromMainThread() via timeout, and there are always a performSelectorOnMainThread in the RunLoop queue. The interesting thing I don't yet understand is why one-shot timer (implemented via CFRunLoopAddTimer), when used for queueing in Docuemnt::postTask works fine and performSelectorOnMainThread causes hang of the test. I'm guessing that timers aren't implemented as a CFRunLoopSource, so have different behavior (they won't starve CFRunLoopSources and won't be starved by them). Whereas performSelectorOnMainThread can starve other CFRunLoopSources. That actually is an interesting idea - perhaps we could implement scheduleDispatchFunctionsFromMainThread() using a 0-delay timer in the case where it's called from the main thread... -atw It looks like events have priority in Cocoa, and I'm guessing that performSelectorOnMainThread() creates events with a higher priority than those generated by URLConnection, which can lead to starvation. I'm not certain what the right fix is, other than to maybe use a different method of dispatching events other than performSelectorOnMainThread that lets us set a lower priority? These main thread calls do not use events for processing. CF/NSRunLoop has a concept of run loop sources, which can generate events or perform other actions, see http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFRunLoopRef/Reference/reference.html and http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopSourceRef/Reference/reference.html . Got it. Doesn't seem like we can affect the order of the CFRunLoopSource used by performSelectorOnMainThread(). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
On 09.03.2010, at 11:51, Drew Wilson wrote: That actually is an interesting idea - perhaps we could implement scheduleDispatchFunctionsFromMainThread() using a 0-delay timer in the case where it's called from the main thread... As an unsubstantiated idea, we could also consider using a run loop observer. These can be set to fire at well defined points of run loop execution. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
That's a great idea: http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivity http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivityThis gives us lots of places to hook. scheduleDispatchFunctionsFromMainThread() could be a no-op on the mac, if we just always invoke dispatchFunctionsFromMainThread() at a specified point in the loop (e.g. kCFRunLoopBeforeWaitingreference.html#//apple_ref/doc/c_ref/kCFRunLoopBeforeWaiting ). The only downside is that I'm not sure how to implement the yield for UI events behavior in dispatchFunctionsFromMainThread() if we're calling this from an observer - we actually need to have some kind of event generated to make sure we wake up. Maybe we could use scheduleDispatchFunctionsFromMainThread() to fire an event to make sure we have something to process, but actually do the processing from within the observer. -atw On Tue, Mar 9, 2010 at 11:55 AM, Alexey Proskuryakov a...@webkit.org wrote: On 09.03.2010, at 11:51, Drew Wilson wrote: That actually is an interesting idea - perhaps we could implement scheduleDispatchFunctionsFromMainThread() using a 0-delay timer in the case where it's called from the main thread... As an unsubstantiated idea, we could also consider using a run loop observer. These can be set to fire at well defined points of run loop execution. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Announcing a WebKit Contributors Meeting on April 12 and 13 at Apple's campus in Cupertino, CA
Hi all- Apple will be hosting a WebKit Contributors Meeting at its campus in Cupertino, CA on Monday, April 12 and Tuesday, April 13 from 9am to 6pm PDT. The meeting is targeted at contributors to the WebKit Open Source Project. The meeting will have an unconference-like format, allowing plenty of time for impromptu sessions/discussions and hacking. A new mailing list, webkit-meet...@lists.webkit.org, will be used for general discussion and to communicate additional information about the meeting. You can subscribe at http://lists.webkit.org/mailman/listinfo.cgi/webkit-meeting . Questions may also be sent to Adele Peterson at ad...@webkit.org. The meeting will be free of charge. All WebKit contributors are encouraged to attend. However, space is limited, so registrations will be accepted on a first come, first served basis. Please register for the meeting using the form at http://webkit.org/meeting/ by Thursday, April 1. We hope to see you there! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
I've tried to post a timer if the scheduleDispatchFunctionsFromMainThread comes on main thread - this fixes the test and it is a minimal change. Drew, let me know if you want to dig deeper in CFRunLoopObserver, otherwise I could whip up a patch (post a timer from main thread + postTask change from Dumi's patch). Dmitry On Tue, Mar 9, 2010 at 12:37 PM, Drew Wilson atwil...@google.com wrote: That's a great idea: http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivity http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivityThis gives us lots of places to hook. scheduleDispatchFunctionsFromMainThread() could be a no-op on the mac, if we just always invoke dispatchFunctionsFromMainThread() at a specified point in the loop (e.g. kCFRunLoopBeforeWaitinghttp://reference.html#//apple_ref/doc/c_ref/kCFRunLoopBeforeWaiting ). The only downside is that I'm not sure how to implement the yield for UI events behavior in dispatchFunctionsFromMainThread() if we're calling this from an observer - we actually need to have some kind of event generated to make sure we wake up. Maybe we could use scheduleDispatchFunctionsFromMainThread() to fire an event to make sure we have something to process, but actually do the processing from within the observer. -atw On Tue, Mar 9, 2010 at 11:55 AM, Alexey Proskuryakov a...@webkit.orgwrote: On 09.03.2010, at 11:51, Drew Wilson wrote: That actually is an interesting idea - perhaps we could implement scheduleDispatchFunctionsFromMainThread() using a 0-delay timer in the case where it's called from the main thread... As an unsubstantiated idea, we could also consider using a run loop observer. These can be set to fire at well defined points of run loop execution. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
Yeah, that seems to be the least invasive. And we're already confident that creating a zero-delay timer won't cause event source starvation, since that's how postTask() used to work. -atw On Tue, Mar 9, 2010 at 12:53 PM, Dmitry Titov dim...@chromium.org wrote: I've tried to post a timer if the scheduleDispatchFunctionsFromMainThread comes on main thread - this fixes the test and it is a minimal change. Drew, let me know if you want to dig deeper in CFRunLoopObserver, otherwise I could whip up a patch (post a timer from main thread + postTask change from Dumi's patch). Dmitry On Tue, Mar 9, 2010 at 12:37 PM, Drew Wilson atwil...@google.com wrote: That's a great idea: http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivity http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopObserverRef/Reference/reference.html#//apple_ref/c/tdef/CFRunLoopActivityThis gives us lots of places to hook. scheduleDispatchFunctionsFromMainThread() could be a no-op on the mac, if we just always invoke dispatchFunctionsFromMainThread() at a specified point in the loop (e.g. kCFRunLoopBeforeWaitinghttp://reference.html#//apple_ref/doc/c_ref/kCFRunLoopBeforeWaiting ). The only downside is that I'm not sure how to implement the yield for UI events behavior in dispatchFunctionsFromMainThread() if we're calling this from an observer - we actually need to have some kind of event generated to make sure we wake up. Maybe we could use scheduleDispatchFunctionsFromMainThread() to fire an event to make sure we have something to process, but actually do the processing from within the observer. -atw On Tue, Mar 9, 2010 at 11:55 AM, Alexey Proskuryakov a...@webkit.orgwrote: On 09.03.2010, at 11:51, Drew Wilson wrote: That actually is an interesting idea - perhaps we could implement scheduleDispatchFunctionsFromMainThread() using a 0-delay timer in the case where it's called from the main thread... As an unsubstantiated idea, we could also consider using a run loop observer. These can be set to fire at well defined points of run loop execution. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::callOnMainThread() and re-entrancy
On 09.03.2010, at 12:37, Drew Wilson wrote: This gives us lots of places to hook. scheduleDispatchFunctionsFromMainThread() could be a no-op on the mac, if we just always invoke dispatchFunctionsFromMainThread() at a specified point in the loop (e.g. kCFRunLoopBeforeWaiting). Something would need to wake up the loop though. Run loop sources and timers do that automatically, but observers do not. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing a WebKit Contributors Meeting on April 12 and 13 at Apple's campus in Cupertino, CA
Is there any way to see who has registered? Or is that something we'll need to make a wiki signup list for or similar? Thanks! -eric On Tue, Mar 9, 2010 at 12:52 PM, Adam Roben aro...@apple.com wrote: Hi all- Apple will be hosting a WebKit Contributors Meeting at its campus in Cupertino, CA on Monday, April 12 and Tuesday, April 13 from 9am to 6pm PDT. The meeting is targeted at contributors to the WebKit Open Source Project. The meeting will have an unconference-like format, allowing plenty of time for impromptu sessions/discussions and hacking. A new mailing list, webkit-meet...@lists.webkit.org, will be used for general discussion and to communicate additional information about the meeting. You can subscribe at http://lists.webkit.org/mailman/listinfo.cgi/webkit-meeting. Questions may also be sent to Adele Peterson at ad...@webkit.org. The meeting will be free of charge. All WebKit contributors are encouraged to attend. However, space is limited, so registrations will be accepted on a first come, first served basis. Please register for the meeting using the form at http://webkit.org/meeting/ by Thursday, April 1. We hope to see you there! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing a WebKit Contributors Meeting on April 12 and 13 at Apple's campus in Cupertino, CA
On Mar 9, 2010, at 4:05 PM, Eric Seidel wrote: Is there any way to see who has registered? Or is that something we'll need to make a wiki signup list for or similar? There isn't currently. Bill Siegrist (_wms) set up the page and knows the details of how hard that would be to do. -Adam On Tue, Mar 9, 2010 at 12:52 PM, Adam Roben aro...@apple.com wrote: Hi all- Apple will be hosting a WebKit Contributors Meeting at its campus in Cupertino, CA on Monday, April 12 and Tuesday, April 13 from 9am to 6pm PDT. The meeting is targeted at contributors to the WebKit Open Source Project. The meeting will have an unconference-like format, allowing plenty of time for impromptu sessions/discussions and hacking. A new mailing list, webkit-meet...@lists.webkit.org, will be used for general discussion and to communicate additional information about the meeting. You can subscribe at http://lists.webkit.org/mailman/listinfo.cgi/webkit-meeting. Questions may also be sent to Adele Peterson at ad...@webkit.org. The meeting will be free of charge. All WebKit contributors are encouraged to attend. However, space is limited, so registrations will be accepted on a first come, first served basis. Please register for the meeting using the form at http://webkit.org/meeting/ by Thursday, April 1. We hope to see you there! -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why I'm reviewing patches outside my area (and why you should too)
On Mar 9, 2010, at 1:45 PM, Adam Barth wrote: (1) The patch needs to be reviewed by David Hyatt. David Hyatt appears to be a bottleneck in the project because he's an expert on a number of components that no one else understands as well but he doesn't spend as much time reviewing patches as Maciej or Darin. I think the best solution here is to have more folks gain expertise in these areas. Dave needs to review this is used as an excuse by others to get out of doing reviews in my opinion. :) MathML is a great example of this. I don't need to be the sole person reviewing MathML patches that don't affect core code. If the MathML rendering code lands in the tree with some mistakes or issues that can be fixed later, it's really not a big deal. Maybe I would have noticed something that another reviewer wouldn't have, but the mistakes will get caught eventually. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing a WebKit Contributors Meeting on April 12 and 13 at Apple's campus in Cupertino, CA
On Mar 9, 2010, at 1:14 PM, Adam Roben wrote: On Mar 9, 2010, at 4:05 PM, Eric Seidel wrote: Is there any way to see who has registered? Or is that something we'll need to make a wiki signup list for or similar? There isn't currently. Bill Siegrist (_wms) set up the page and knows the details of how hard that would be to do. Its not hard, but I did not make a public page for that since it could have some privacy implications. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why I'm reviewing patches outside my area (and why you should too)
(3) Someone reviewed an earlier version of the patch but then didn't follow up. I think having a partial review by one person encourages other people to assume that person will finish the review. That cause the patch to float upwards in pending-review until it gets lost in the sea of ancient patches. I'd encourage reviewers to follow through with their reviews Don't be afraid of r-ing a patch. Believe me, folks are thankful for feedback (even negative feedback) when their patches have been sitting around collecting dust. However as soon as you r- a patch, according to 3, you need to finish the review when it gets re-submitted. This leads me to believe that *one shouldn't avoid a patch that has feedback from someone else* unless one doesn't feel qualified to judge whether the feedback has been addressed. I plea to folks submitting patches: 1. Keep your patches as small as possible. It is no fun to deal with a 60K patch. 2. Review your own patches before or right after you attach them to the bug as if you were reviewing someone else's code. 3. Address any style issues, build issues that the bots notice. You don't need to wait for a review to point out the same issue. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why I'm reviewing patches outside my area (and why you should too)
On Tue, Mar 9, 2010 at 9:39 PM, David Levin le...@chromium.org wrote: (3) Someone reviewed an earlier version of the patch but then didn't follow up. I think having a partial review by one person encourages other people to assume that person will finish the review. That cause the patch to float upwards in pending-review until it gets lost in the sea of ancient patches. I'd encourage reviewers to follow through with their reviews Don't be afraid of r-ing a patch. Believe me, folks are thankful for feedback (even negative feedback) when their patches have been sitting around collecting dust. However as soon as you r- a patch, according to 3, you need to finish the review when it gets re-submitted. This leads me to believe that *one shouldn't avoid a patch that has feedback from someone else* unless one doesn't feel qualified to judge whether the feedback has been addressed. I plea to folks submitting patches: 1. Keep your patches as small as possible. It is no fun to deal with a 60K patch. 2. Review your own patches before or right after you attach them to the bug as if you were reviewing someone else's code. 3. Address any style issues, build issues that the bots notice. You don't need to wait for a review to point out the same issue. It's also a big help when peers (which aren't necessarily WebKit reviewers) look over it and give review-style feedback as well. Especially when said peers know more about that code than any of the official reviewers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why I'm reviewing patches outside my area (and why you should too)
On Tue, Mar 9, 2010 at 11:45 AM, Adam Barth aba...@webkit.org wrote: Q: Why are you doing this? You should stick to reviewing code in your own area. A: The pending-review queue is out of control. It's past the tipping point where there are too many patches for someone to reasonably look at the queue. It's not healthy for the project to leave patches unreviewed for over a month. Someone needs to step up. If not me, then who? snip If you're a reviewer, I'd encourage you to work through pending-review from oldest to newest. Don't be afraid of r-ing a patch. Believe me, folks are thankful for feedback (even negative feedback) when their patches have been sitting around collecting dust. Also, it's OK to comment on a patch with a suggestion as to how to make it more easily reviewable. As an example, Eric noted on this patch of mine ( https://bugs.webkit.org/show_bug.cgi?id=35314) that most of the layout test changes could be committed as a separate patch before making any code changes and that would make verifying correctness of the code changes easier. While it was probably more work for me, I appreciated the opportunity to make progress instead of just stalling. Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore and the V8 debugger protocol
Hey Jamey, Thanks for the links and explanation. I am still incredibly new to the codebase, but it looks like you have done much of what I need. However, I am only using the JavaScriptCore portion of Webkit. I am under the impression the changes you made require WebCore to perform the remote debugging. Likewise, the trunk code is coupled similarly for local debugging. I wonder if coupling the debugging helper classes for JSC with WebCore is ideal. It appears that ScriptDebugServer could be separated into portions that do not require WebCore, that would facilitate the building of a debugger for just JSC. Since you are on the precipice of forming a consensus, it might be worth designing the remoting so it could be used at a lower level. -Jonathan From: jamey.hi...@nokia.com [mailto:jamey.hi...@nokia.com] Sent: Tuesday, March 09, 2010 5:31 AM To: Fischoff, Jonathan Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] JavaScriptCore and the V8 debugger protocol Hi Jonathan, I've been working on remote debugging/profiling of webkit and I've been leveraging work that the webkit and chromium guys did to separate the Web Inspector frontend from backend. I was actually thinking about sending email to the list this morning about agreeing on a remote/on-device protocol for debugging and profiling webkit. It is possible to replace the javascript in the Web Inspector front-end in order to enable a remote connection to the Web Inspector backend. Once you do that, you can remotely debug, inspect, and profile your code. I have made two prototypes enable remote debugging. In these two prototypes, I have used the Web Inspector UI running in Safari or WebKit on a desktop connected to the backend running in a webkit instance on another device. My first prototype was all implemented in C++ for qtwebkit. There is a patch with this code: Qt debug agent partially implementing ChromeDevTools and V8 debug protocolhttps://bugs.webkit.org/attachment.cgi?id=48913 attached to https://bugs.webkit.org/show_bug.cgi?id=35016 Given the feedback on that set of patches, I've been working on a javascript debug agent with this patch to load alternate inspector javascript: https://bugs.webkit.org/show_bug.cgi?id=35340 I also did a partial implementation of the ChromeDevTools protocol and a V8Debug protocol adapter for JavaScriptCore. In discussions with some of the Chromium guys, it sounds like they would like to move ChromeDevTools protocol closer to the internal protocol used by WebKit. I would like to see a stable inspection/profiling/debug protocol for WebKit and JavaScriptCore. Best regards, Jamey Hicks On Mar 8, 2010, at 7:18 PM, ext Fischoff, Jonathan wrote: I would like to control JavaScript execution in my app remotely using the V8 debugger protocol. Does anyone know if there exists code that implements and the V8 debugger protocol for JavaScriptCore? My main goal is remotely debug JavaScript, so I am also wondering what other technologies exist for remotely debugging JavaScriptCore. Any ideas? -Jonathan Fischoff ATT1..txt ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKitGTK+ on Snow Leopard
Hi, Has someone actually been able to compile WebKitGTK+ on Snow Leopard? I have retrieved all the dependancies via Mac ports and fink and always seem to get hung up on libjpeg where the compiles believes the library is missing when it is not. This is not the right mailing list for compiling issues. Webkit-dev is for WebKit's internal development. You would have better answers on either webkit-help or webkit-gtk (see http://lists.webkit.org/mailman/listinfo). Also your description is too broad for someone to really be able to help you: what is the last command that is executed? When does it hang up: before compilation, compilation, link...? What have you already tried to solve this? (make sure to read http://bit.ly/webkit-gethelp so that you can get accurate answers) Regards, Julien ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Leopard Release Builder offline
http://build.webkit.org/builders/Leopard%20Intel%20Release%20%28Tests%29/ Looks like the build slave is offline. Any Apple person able to kick the slave? -eric p.s. For any commit-queue users: Since the build was red when it went offline, the commit-queue will be blocked until it's back. http://webkit-commit-queue.appspot.com/ (12 patches currently in the queue.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Leopard Release Builder offline
We're having hardware troubles with this machine. It might not *be* back for a bit. I apologize for the negative effect this has on commit-queue users, but it's out of our control at this point. ~Brady On Mar 9, 2010, at 7:27 PM, Eric Seidel wrote: http://build.webkit.org/builders/Leopard%20Intel%20Release%20%28Tests%29/ Looks like the build slave is offline. Any Apple person able to kick the slave? -eric p.s. For any commit-queue users: Since the build was red when it went offline, the commit-queue will be blocked until it's back. http://webkit-commit-queue.appspot.com/ (12 patches currently in the queue.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Questions regarding memory debugging
HI All, I'm currently running the iexploder tests on GtkLauncher and I'm observing a growth in memory usage of that process. I have used the GNOME memprof utilitiy to look at it and the best candidate for the leak is SharedBuffer::append which will allocate memory. Now SharedBuffer is refcounted and can only leak if someone is holding a reference to it and this is where stuff gets tricky. Besides manually searching the tree and adding printf's all over has anyone found a better way of doing this? At the OpenBSC GSM Project we are using this C library talloc. With talloc every allocation is happening inside a (hierachical) context and at runtime we can send a SIGUSR1 one to the application and the memstatistics are dumped on the console. I have attached an example output so you guys can see it. I wonder if such a thing would make sense in a debug build as well? I wonder if we could change the common Class::create methods to take a context, or at least an area (Render, Network, Platform) and if these get created in a special debug build we add these objects to a list for these contexts and we can dump the information... e.g. # of allocated bytes, ref count and such? Does this sound crazy or too invasive? comments? talloc report on 'vty' (total 26810 bytes in 2351 blocks) save_cwd contains 37 bytes in 1 blocks (ref 0) 0x92d18d0 vty_commandcontains 15093 bytes in 1180 blocks (ref 0) 0x92d1898 vty_vector contains 11680 bytes in 1169 blocks (ref 0) 0x92d1860 full talloc report on 'openbsc' (total 85562 bytes in 54 blocks) struct ia_e1_handlecontains 60 bytes in 1 blocks (ref 0) 0x92f74a8 telnet_connection contains 1 bytes in 1 blocks (ref 0) 0x92c50a0 struct gsm_network contains 84860 bytes in 5 blocks (ref 0) 0x92c3830 struct gsm_bts contains 84604 bytes in 2 blocks (ref 0) 0x92f7ad8 struct gsm_bts_trx contains 82092 bytes in 1 blocks (ref 0) 0x92f84e0 OpenBSCcontains 8 bytes in 1 blocks (ref 0) 0x92c51f8 OpenBSCcontains 8 bytes in 1 blocks (ref 0) 0x92c2cd0 countercontains500 bytes in 26 blocks (ref 0) 0x92ac568 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92c6a78 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b2ae8 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b2aa0 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b2a58 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b2a10 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b29c8 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b2980 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b2938 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92c2c10 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92c2bc8 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92c2b80 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92c2b38 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92c2af0 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b3b48 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b3b00 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b3ab8 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b3a70 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92ae140 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92ae0f8 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92ae0b0 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b0250 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b0208 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92c5058 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92b0178 struct counter contains 20 bytes in 1 blocks (ref 0) 0x92c5110 trau_upq_entry contains 0 bytes in 1 blocks (ref 0) 0x92ac530 trau_map_entry contains 0 bytes in 1 blocks (ref 0) 0x92ac4f8 transactioncontains 0 bytes in 1 blocks (ref 0)
Re: [webkit-dev] Why I'm reviewing patches outside my area (and why you should too)
Hi, It's also a big help when peers (which aren't necessarily WebKit reviewers) look over it and give review-style feedback as well. Especially when said peers know more about that code than any of the official reviewers. Is that really help? Sometimes when a patch looks good to me, it still rots in the bugzilla for weeks. On the other hand, sometimes I have concerns about the patch, and somebody just pop in and give an r+ without any comments. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
