Re: [webkit-dev] Sunsetting committership and reviewership
How about creating an 'emeritus reviewer' status (no r+ power) and let people *voluntarily* move themselves to this status? I bet a lot of 'inactive reviewers' would do that, since everybody understands the issue of getting out of sync with current code base. It may have different vibe though than figuring some automatic time-based enforcement system... As an added bonus, this gives such people a good way to avoid being asked to review a patch for a colleague while keeping some ties with the project... On Mon, Apr 8, 2013 at 3:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. We sometimes get low-quality drive-by reviews even from people who are active at the time. I feel like that's not the right basis for the time cutoff. If we do have a sunset period, we should think about it in terms of how long it takes to be so out of touch with the current state of the project that there's little chance you can give a useful review. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Magic Iframe removal proposed
Hi, There is a patch posted https://bugs.webkit.org/show_bug.cgi?id=81590 for removal of the 'magic iframe' feature. This is the ability to move 'live' iframe from one page to another w/o unloading it. If you have interest or ideas about this feature, please reply. HISTORY This feature was added 2 years ago (bug herehttps://bugs.webkit.org/show_bug.cgi?id=32848). It was intended as a shared app context for complex apps that span several pages. In case when random set of pages is closed, the surviving iframe could be passed between remaining pages and serve as 'app state'. This behavior is somewhat described in HTML5 spechttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element: Removing an iframe from a Document does not cause its browsing context to be discarded. Indeed, an iframe's browsing context can survive its original parent Document if its iframe is moved to another Document. All non-WebKit browsers don't have this and always unload the iframe when it is disconnected form the document. PROBLEMS We did have quite a few issues with this mechanism. The root of the problem seems to be that traditionally, multiple 'permissions' and 'live objects' are associated with a top-level page, or a top frame of some kind, instead of being associated with each Frame. Even HTML specifications often formulate the scope of things like permissions in terms of a page - for example, geo permissions are computed based on the origin of the page. When an iframe is transferred from one page to another, it may enter a different set of permissions while already performing operations authorized before. Association with the top-level page is also used to determine which one should show modal UI for HTTP Auth, per-origin permissions, or certificate issues for example. As a result, we had quite a few bugs popping up (and fixed). WHY REMOVE This is somewhat obscure feature of the platform. Only a few apps that we knew used the feature. Most developers, both app and webkit kind, don't even know about it. When new mechanisms/APIs are implemented, a lot of objects get associated with Page (WebView) level and they are almost 'automatically' broken in case of live iframe transfer because once old page closes, it destroys the objects with lifetimes scoped by it. This makes it somewhat dangerous and difficult to support. The benefits that it gives to the big multi-page applications do not seem to warrant the actual complexity of maintaining this feature. Other browsers never implemented the feature, siting difficult design due to various thorny security issues as well. This is potentially a compatibility issue for sites that use document.adoptNode(iframe) to ensure live transfer of an iframe from one page to another. In the future, if there will be sufficient need, it is possible to design a 'shared module' feature that would explicitly deal with various security/lifetime boundaries. Please let us know what you think. Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Magic Iframe removal proposed
On Mon, Mar 19, 2012 at 6:09 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitry. Two thoughts on this: (1) If we remove this feature, are Chromium/GMail developers going to re-request the other shared document features that this feature subsumed? Or are y'all now convinced that shared document is, in general, not a good idea? On a contrary, 'shared application state' could be a good idea, however this particular way to implement it unfortunately is very difficult to get right. There are no Google applications that use this feature currently, and there is understanding of the costs involved. There is a possibility that some other idea can both address the potential need and be reliably implementable at the same time. Workers, for example, are a good case of limiting the surface that also limits design/maintenance costs. Perhaps something similar can be proposed for shared state. However, there was a discussion in Chromium and it appears that ongoing design and maintenance of magic iframe is not worth the benefit the feature provides for the applications. The reason I ask this is that, given your description, I see some problems with the shared iframe feature, but I still think it's much better than previously proposed alternatives. (2) I think you should share your data with the relevant standards bodies, and suggest a change to the HTML5 spec, if you haven't done so already. I wouldn't want to remove this feature just to add it back later for the sake of spec compliance. Good suggestion, will do. Just wanted to give WebKit community a heads-up... Thanks, Geoff On Mar 19, 2012, at 5:51 PM, Dmitry Titov wrote: Hi, There is a patch posted https://bugs.webkit.org/show_bug.cgi?id=81590for removal of the 'magic iframe' feature. This is the ability to move 'live' iframe from one page to another w/o unloading it. If you have interest or ideas about this feature, please reply. HISTORY This feature was added 2 years ago (bug herehttps://bugs.webkit.org/show_bug.cgi?id=32848). It was intended as a shared app context for complex apps that span several pages. In case when random set of pages is closed, the surviving iframe could be passed between remaining pages and serve as 'app state'. This behavior is somewhat described in HTML5 spechttp://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element: Removing an iframe from a Document does not cause its browsing context to be discarded. Indeed, an iframe's browsing context can survive its original parent Document if its iframe is moved to another Document. All non-WebKit browsers don't have this and always unload the iframe when it is disconnected form the document. PROBLEMS We did have quite a few issues with this mechanism. The root of the problem seems to be that traditionally, multiple 'permissions' and 'live objects' are associated with a top-level page, or a top frame of some kind, instead of being associated with each Frame. Even HTML specifications often formulate the scope of things like permissions in terms of a page - for example, geo permissions are computed based on the origin of the page. When an iframe is transferred from one page to another, it may enter a different set of permissions while already performing operations authorized before. Association with the top-level page is also used to determine which one should show modal UI for HTTP Auth, per-origin permissions, or certificate issues for example. As a result, we had quite a few bugs popping up (and fixed). WHY REMOVE This is somewhat obscure feature of the platform. Only a few apps that we knew used the feature. Most developers, both app and webkit kind, don't even know about it. When new mechanisms/APIs are implemented, a lot of objects get associated with Page (WebView) level and they are almost 'automatically' broken in case of live iframe transfer because once old page closes, it destroys the objects with lifetimes scoped by it. This makes it somewhat dangerous and difficult to support. The benefits that it gives to the big multi-page applications do not seem to warrant the actual complexity of maintaining this feature. Other browsers never implemented the feature, siting difficult design due to various thorny security issues as well. This is potentially a compatibility issue for sites that use document.adoptNode(iframe) to ensure live transfer of an iframe from one page to another. In the future, if there will be sufficient need, it is possible to design a 'shared module' feature that would explicitly deal with various security/lifetime boundaries. Please let us know what you think. Thanks, Dmitry ___ 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
Re: [webkit-dev] Git/SVN is slow
over here in Seattle I am getting 5KiB/s all day, no way to get an updated checkout today :-( On Thu, Mar 15, 2012 at 10:54 AM, Jarred Nicholls jar...@webkit.org wrote: Well I was just about to follow up that from the east coast on Comcast bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s. That's about as fast as it's always been. Same goes for nightly.webkit.org. There's a number of possible issues that would result in slow response times and slow downloads. E.g., it could be sheer packet loss between carrier backbones and not necessarily tapped bandwidth. On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa rn...@webkit.org wrote: I don't really think checking the latency is interesting. What's killing us is bandwidth. As far as I tested yesterday, the ping at my work (Google SF office) gives me a reasonable time as well. There's something that's killing our bandwidth. Does anyone know some tools to investigate this? - Ryosuke On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls jar...@webkit.orgwrote: Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings to svn.webkit.org succeed in acceptable times however, for me. Perhaps the hops following ae-11-70 and ae-21-60 simple aren't able to reply with proper ICMP packets; no real conclusion to based on that info alone, but maybe worth passing off to the provider and/or directly to Level3. Jarred On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub le...@google.comwrote: Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates are dog slow :( 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 ms * 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 ms 3.056 ms 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms 9 * * * 10 * * * 11 * * * On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers p...@google.com wrote: Bill, I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor http://build.webkit.org/console hits the page refresh before it's even able to render to the bottom :( Below is a traceroute to webkit.org: traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 ms 15.541 ms 15.733 ms 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 ms 16.929 ms 16.946 ms 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net(68.86.93.125) 14.599 ms 11.428 ms 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms 34.950 ms 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms 66.692 ms 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms 78.175 ms 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Thanks for looking into this. Philip On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist wsiegr...@apple.com wrote: Our network provider did not find anything wrong. If anyone is currently seeing slow download times, I would like to see a traceroute to the server. Thanks, -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list
Re: [webkit-dev] how to create a test that can perform actions while resources are still loading?
It will work, but you need to add more to it, like this:
?php
header(Expires: Thu, 01 Dec 2003 16:00:00 GMT);
header(Cache-Control: no-cache, no-store, must-revalidate);
header(Pragma: no-cache);
header(Content-Type: text/html; charset=utf-8);
echo(scriptparent.reportLoading('start')/script);
echo(body);
for ( $counter = 0; $counter = 1000; $counter += 1) {
echo(spanA bunch of text in the body/span);
}
sleep(2);
echo(scriptparent.reportLoading('done')/script);
?
The trick is to make the text big enough for various network components to
decide to stop accumulating bytes and send them to the receiver. 'flush()'
etc may only affect part of the pipeline. The example above runs a loop and
builds up enough text in the body. That makes using 'flush()' unnecessary as
well.
Also, I believe we have a bug in TextResourceDecoder::checkForHeadCharset,
it has incorrect condition for exit from the loop. This function tries to
find 'charset' in head section or in first 1024 bytes, whatever ends last.
Unfortunately, it checks for 1024 only on tag boundaries after first
non-head tag, so if you have a huge body with just text in it, the parser
will never receive a byte before /body. I'll fix this soon but for now
those span tags in the loop will do the trick.
Dmitry
On Thu, Oct 7, 2010 at 5:12 PM, Jenn Braithwaite (胡慧鋒) je...@google.comwrote:
I need the inline script to be in the iframe content so that the test does
not execute until the iframe has started loading (but has not completed). I
tried the php below, but the script doesn't execute until after the sleep. I
don't know php. Is my php wrong? Or does DRT buffer the response until the
entire response is complete?
?php
header(Expires: Thu, 01 Dec 2003 16:00:00 GMT);
header(Cache-Control: no-cache, no-store, must-revalidate);
header(Pragma: no-cache);
header(Content-Type: text/html; charset=utf-8);
echo(scriptparent.opener.test();/script);
ob_flush();
flush();
sleep(10);
?
Thanks,
Jenn
On Thu, Oct 7, 2010 at 8:15 AM, Ojan Vafai o...@chromium.org wrote:
On Wed, Oct 6, 2010 at 4:42 PM, Darin Adler da...@apple.com wrote:
On Oct 6, 2010, at 4:36 PM, Jenn Braithwaite (胡慧鋒) wrote:
I've also tried making this an http test using a slow loading iframe,
but the window onload handler for the page does not run until after its
iframe has finished loading.
This seems OK. You can put your test code somewhere other than the load
handler. For example, an inline script:
script
test();
/script
That will run right away and won’t wait for the window load event.
I'm not 100% sure, so take this with a grain of salt, but I think there
are cases where iframes the load immediately (e.g. if the resource is
cached).
To avoid race conditions, I think you need the frames to actually never
finish loading. I thought there were some HTTP tests that have resources
that intentionally never finish loading. I'd look in the
LayoutTests/http/tests for files with 'slow' in the name.
Ojan
___
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] Misplaced files
Considering there are already specific WebCore subdirs for notifications, storage, workers, svg, mathml and others, it seems having a new subdirectory named perhaps 'blob' wouldn't be out of line. There is quite a few of those Blob/File files already... Dmitry On Fri, Aug 27, 2010 at 3:55 PM, Adam Barth aba...@webkit.org wrote: Looking through WebCore/html I noticed the files below. I'm not sure they belong in WebCore/html because they don't appear to be HTML-specific. Rather, they seem like generic web platform APIs (e.g., they could be exposed to SVG or whatever other markup languages we choose to support in the future). Should we move these to WebCore/page, WebCore/dom, or should we make a new location for these sorts of things? Adam == Blob-related == Blob.cpp Blob.h Blob.idl BlobBuilder.cpp BlobBuilder.h BlobBuilder.idl BlobURL.cpp BlobURL.h ThreadableBlobRegistry.cpp ThreadableBlobRegistry.h == File-related == File.cpp File.h File.idl FileError.h FileError.idl FileList.cpp FileList.h FileList.idl FileReader.cpp FileReader.h FileReader.idl FileStreamProxy.cpp FileStreamProxy.h FileThread.cpp FileThread.h FileThreadTask.h FileWriter.cpp FileWriter.h FileWriter.idl ___ 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] Does any port implements Navigator.registerProtocolHandler and Navigator.registerContentHandler?
Thanks to all, the bug is here: https://bugs.webkit.org/show_bug.cgi?id=41878 I've added link to tracking Chromium bug as well. Dmitry On Wed, Jul 7, 2010 at 7:59 PM, Jeremy Orlow jor...@chromium.org wrote: That would be the standard thing to do. The sooner someone gets started on the feature, the easier it'll be to revert the patch that removes the code. :-) J On Thu, Jul 8, 2010 at 10:55 AM, David Levin le...@chromium.org wrote: On Wed, Jul 7, 2010 at 5:24 PM, Peter Kasting pkast...@google.comwrote: On Wed, Jul 7, 2010 at 5:00 PM, Dmitry Titov dim...@chromium.orgwrote: I'd lean to the removal, unless there is a port that has work ongoing or planned soon for those implementations. Does anybody vote for #ifdefs? I vote against removal if only because Chromium has really wanted these badly for a long time and simply hasn't been able to find someone to implement them. Perhaps I could make it worth your while to implement rather than remove the stubs? :) *Even if someone to implement them for chromium, it doesn't seem to fix the overall problem. *Dmitry indicated that the presences of these is breaking feature detection in browsers using WebKit (-- which is something being heard from web developers). A simple solution is to remove them. Later, any port (including chromium) who gets someone to work on them could re-add these methods back properly under ifdef's. dave ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Behavior of file:// URLs when dragging
On Mon, May 10, 2010 at 5:48 PM, Daniel Cheng dch...@chromium.org wrote: From the discussion on https://bugs.webkit.org/show_bug.cgi?id=25882, I believe the general consensus is that file:// URLs should not be exposed when dragging and dropping. Removing file:// URL population from event.dataTransfer is pretty easy; however, what should we do when the user drops a file in an editable area? Right now, it creates a link with the file URL, which (I think) defeats the point of removing file:// URLs from event.dataTransfer. I think the right behavior here is to return DragOperationNone unless the active target element is a file input or it's a non-editable element that handles files in event.dataTransfer, but I'd like to see what other people think first. I think there was a suggestion in that bug to only drop the filename into the editable area, without the full path. I'm not sure if it is better then DragOperationNone though. On a tangent, I noticed that a lot of implementations of DragData::asURL try to check that a file URL points at a file that actually exists. What is the rationale for doing the file existence check in DragData? The loader has to check for existence anyway, so why not just let the loader do it? This should save some IO time, especially if the file is on a slow NFS share in another continent. Does anyone depend on asURL's undocumented behavior to not return file URLs that point to non-existent files? (If so, I'd be willing to argue that they shouldn't be doing that anyway.) If not, I'd like to remove that behavior. Daniel ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Crashing Workers Code?
I believe thee is more then one underlying issue. For example, tests that fail with CONSOLE MESSAGE: line 3: JavaScript execution exceeded timeout. - seems this is legit since JSC workers are terminated by setting a 1-ms timeout. V8 workers terminate by throwing exception of a special kind and then checking for it in C++ code. In JCS case, we likely should disable the message once WorkerThread::stop() was invoked. I'm trying to catch one elusive crash for some time now. It's in Chromium but perhaps it's the same thing. It manifests like this: ASSERTION FAILED: !m_sharedBuffer (/b/slave/mac/build/src/third_party/WebKit/WebCore/WebCore.gyp/../platform/text/StringImpl.cpp:59 WebCore::StringImpl::~StringImpl()) or like this: Test: worker-cloneport.html Chromium Helper(1774,0xb00a1000) malloc: *** error for object 0x241e260: double free *** set a breakpoint in malloc_error_break to debug Chromium Helper(1774,0xb00a1000) malloc: *** error for object 0x241e280: incorrect checksum for freed object - object was probably modified after being freed. There is some race going on... But not frequent enough to easily find it :-( Dmitry On Mon, Mar 29, 2010 at 4:54 PM, Eric Seidel e...@webkit.org wrote: It seems Workers makes for a disproportionate number of crashes and flaky tests on the bots: https://bugs.webkit.org/show_bug.cgi?id=36646 (timeout) https://bugs.webkit.org/show_bug.cgi?id=36633 (crash) https://bugs.webkit.org/show_bug.cgi?id=36585 (timeout) https://bugs.webkit.org/show_bug.cgi?id=29926 (crash) https://bugs.webkit.org/show_bug.cgi?id=29090 (timeout) https://bugs.webkit.org/show_bug.cgi?id=34281 (timeout) https://bugs.webkit.org/show_bug.cgi?id=33653 (crash) https://bugs.webkit.org/show_bug.cgi?id=33437 (crash) https://bugs.webkit.org/show_bug.cgi?id=33008 (crash) I have not tried running a full run-webkit-tests with --guard, but I suspect there may be some sort of memory smasher or other corruption problem which has been flying under our radar for a long while. Unfortunately I don't know more than that yet... -eric ___ 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] Crashing Workers Code?
On Mon, Mar 29, 2010 at 5:26 PM, Darin Adler da...@apple.com wrote: On Mar 29, 2010, at 5:14 PM, Dmitry Titov wrote: JSC workers are terminated by setting a 1-ms timeout. V8 workers terminate by throwing exception of a special kind and then checking for it in C++ code. There is precedent in JavaScriptCore for using a special exception to terminate code. InterruptedExecutionError is used for this purpose. I could imagine having something similar for workers. A timeout sounds like a poor way to do it. Indeed. Added this info to https://bugs.webkit.org/show_bug.cgi?id=36646 and renamed it. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Chromium layout test expectations coming today
For now, I've just used a shortest notation: http://trac.webkit.org/changeset/56582 It's easy to change if this thread will come to a resolution. Since it's copy/paste to browser anyways, the bug number works as well as url perhaps. Dmitry On Mon, Mar 22, 2010 at 2:03 PM, Dirk Pranke dpra...@chromium.org wrote: On Fri, Mar 19, 2010 at 7:06 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 19, 2010, at 5:30 PM, Ojan Vafai wrote: Currently we do BUG12345 for Chromium bugs. There are no WebKit bugs listed. How about we instead use CR12345 for Chromium bugs and WK12345 for WebKit bugs? Another possibility would be to use bug URLs. The current expectations file has lines that (barely but) usually clock in at under 80-characters. I am reluctant to change things that make it more effort for a user to type in and make it harder to read by going over 80 characters and wrapping. I'm not sure what real advantage would be gained by making it a URL to offset this. I have rarely found myself cutting-and-pasting or clicking on stuff from this file. So, I would vote for a shorter shortcut, like the 3-4 character prefixes that have been suggested. -- Dirk ___ 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] FileAPI/FileWriter support
I'm curious what the ByteStore object is for? While reading the document, I've got an impression that BlobBuilder would store all content of the blob under construction in that store, 'realizing' the parts (encoding the strings into utf-8 and reading the files underlying Blobs). It seems to be better to avoid 'realizing' the separate strings/blobs until the very end (basically, until the bits are needed for actual XHR.send() or FileWriter.write()), otherwise BlobBuilder.append() becomes a synchronous read whole file operation. Dmitry On Wed, Mar 24, 2010 at 5:42 PM, Kinuko Yasuda kin...@chromium.org wrote: Hi webkit-dev folks, I'm working on FileAPI/FileWriter support and would like to start making changes / send patches for the work. Our initial target platform is chromium and many of the changes will only touch files under platform/chromium, but I will also change existing Blob/File code and will add some modules in WebCore for async file operations. Here's the design doc (implementation plan) for FileWriter: http://docs.google.com/View?docID=0AWoCez0NQ60KZG5jaGhkZ18xZ25rZ3RxY3Arevision=_latesthgd=1 The plan/design is not concrete yet and any feedbacks are more than welcome. To start with, I'm planning to open a new meta issue for FileWriter (will also update webkit.org/b/32624) and start submitting changes in small pieces whenever possible. Thanks! Kinuko ___ 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] Question regarding build flags for the features
If we had a single flag for all those (ENABLE_FILE_API ?) then a port would have to implement all features at once to be able to enable it. It might be inconvenient. If the code is not shared and those flags can be enabled in any combination, why not keep them separate? On a related note, it'd be nice to have a page (on a wiki?) with a list of those flags with some sort of a status/owner, and possibly some info on what a port should implement to be able to enable a feature. On Tue, Mar 23, 2010 at 10:11 AM, Jian Li jia...@chromium.org wrote: Hi, I've introduced a build flag ENABLE(BLOB_SLICE) for the Blob.slice feature. To continue implementing other File API features, we probably need a couple more build flags, like ENABLE(FILE_URN) and ENABLE(FILE_READER). When the embedder implements the necessary support, these flags can be turned on respectively. Do we want to use multiple flags to control File API features or simply use one flag? For the latter, all the features will only be available after the embedder hooks up all the supporting logics. Thanks, Jian ___ 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] Compile failures on Leopard build bot
Hi! One of 2 slaves (apple-xserve-1 ../../../buildslaves/apple-xserve-1) on that bot fails Release compile: http://build.webkit.org/builders/Leopard%20Intel%20Release%20(Build)/builds/12151 It seems like because of incremental build after http://trac.webkit.org/changeset/54411, it now has DOMBlob.h file in both WebKitBuild/Release/WebKit.framework/Headers and PrivateHeaders. Could someone with access to this machine take a look (or just clobber/delete the file?) Thanks! Dmitry ___ 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
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
On Mon, Mar 8, 2010 at 11:38 AM, Alexey Proskuryakov a...@webkit.org wrote: 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 ___ 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
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.org wrote: 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 ___ 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
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit-changes] [55234] trunk/JavaScriptCore
On Thu, Feb 25, 2010 at 9:48 AM, Jochen Eisinger joc...@chromium.orgwrote: Here's a bit of context. When a database is opened, right now you don't have any context from where it is opened. The problem is that the actual calls that open a database go through the sqlite3 vfs layer, so there's no easy way to pass this function down to to platform/sql/chromium/SQLFileSystemChromium*.cpp This patch will allow you to get from anywhere within webkit a pointer to the Thread object that actually created the thread you're currently on Would TLS mechanism provide the same thing? (in case of the database, this can be either a thread forked of from the main thread or from a worker thread), and query the object for context information. I hope this explains this. best -jochen On Thu, Feb 25, 2010 at 6:31 PM, Alexey Proskuryakov a...@webkit.org wrote: There is not a single word explaining this change - neither in ChangeLog, nor in the bug. Such a patch shouldn't have been accepted. Is there any reason not to roll it out? - WBR, Alexey Proskuryakov On 25.02.2010, at 6:49, e...@webkit.org wrote: revision55234authore...@webkit.orgdate2010-02-25 06:49:12 -0800 (Thu, 25 Feb 2010) Log Message 2010-02-25 Jochen Eisinger joc...@chromium.org Reviewed by Jeremy Orlow. Make the context that was passed to the ThreadFunction accessible. https://bugs.webkit.org/show_bug.cgi?id=35379 * wtf/Threading.h: * wtf/ThreadingNone.cpp: (WTF::threadContext): * wtf/ThreadingPthreads.cpp: (WTF::): (WTF::identifierByPthreadHandle): (WTF::establishIdentifierForPthreadHandle): (WTF::pthreadHandleForIdentifier): (WTF::contextForIdentifier): (WTF::createThreadInternal): (WTF::currentThread): (WTF::threadContext): * wtf/ThreadingWin.cpp: (WTF::): (WTF::threadMap): (WTF::storeThreadHandleByIdentifier): (WTF::threadHandleForIdentifier): (WTF::contextForIdentifier): (WTF::createThreadInternal): (WTF::threadContext): ___ 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] The tree is on fire
Ok, I believe r53727 and r53738 are going to fix Leopard and SnowLeopard (and improve Windows) test runs. Keeping an eye on it... ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Database in Worker context
+1 to small patches. I've reviewed a couple of iterations of the patch in https://bugs.webkit.org/show_bug.cgi?id=22725 and it was so far manageable, although it could be split in 2 at least (inheritance change and WorkerThread termination change). For future patches, definitely lets split into smaller ones, 60kb is on a biggish side. There is no DatabaseManager class anymore since the database-supporting methods are being moved to ScriptExecutionContext from which both Document and WorkerContext are derived from. Having a 'Context' to own another 'Manager' seemed like too much layers. I lean to r+ the first patch after latest set of notes is addressed, more eyes are always welcome though :-) Dmitry On Thu, Jan 14, 2010 at 3:06 PM, Darin Adler da...@apple.com wrote: On Jan 14, 2010, at 2:35 PM, Eric Uhrhane wrote: I think it would have been hard to break this chunk any smaller. Any time you have a chunk and you’re wondering how it could be broken up smaller, please feel free to ask that question after cc'ing me on a bug. Maciej and I, in particular, have a lot of experience with this, much of dating from the first year of the Safari project. I made changes that were too large and learned “no apologies” strategies to break them up into much smaller pieces that were easier to get right and to read and review. -- Darin ___ 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] SharedScript: next steps and result of offline discussion.
On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote: On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher da...@chromium.org wrote: I think that use case has been de-emphasized. However, if we wanted to support it, we'd probably have to say that removeChild of an IFRAME element doesn't cause the unload event to be dispatched. (I'm a bit concerned that that may cause incompatibilities with existing pages.) Then, you'd have to store a reference to the IFRAME element in a global variable, so that you could find it again when the next document is loaded. I hope this use-case can be accommodated, I think this is ultimately the more generally applicable use-case. Btw, concern for incompatibilities with existing pages was one reason we came up with a new construct for this capability (instead of overloading iframe or script). If you want to minimize new work on a page transition, then you should use history.pushState and alter the content in place. Saving a subsite of live script and DOM objects across a full page load does not seem useful to me, since likely removing the full page load will be a bigger improvement to load time and responsiveness. This assumes that pages are heavy I believe. The use case was about having most of the load in the shared object and pages being light UI 'frames'. This would allow to use regular URLs and history management of the browser directly. Moving most of the code and parking DOM (like editor chrome) in a shared object could enable very lightweight pages. It sounds a bit theoretical now but the hope was that it brings interesting way of building apps in a way which could be better and perhaps simpler then building heavy non-navigatable ajax pages that have to generate content and use onbeforeunload to warn user that moving away is a bad idea :-) Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WTF::currentThread() and non-WTF threads
Thanks for sharing your thoughts!
On Fri, Dec 11, 2009 at 2:44 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Dec 10, 2009 at 6:48 PM, Dmitry Titov dim...@chromium.org wrote:
Hi webkit-dev!
Trying to add ASSERTS to RefCounted objects (
https://bugs.webkit.org/show_bug.cgi?id=31639) I've added some more calls
to WTF::currentThread() and started to get a lot of assertions here:
static ThreadIdentifier establishIdentifierForPthreadHandle(pthread_t
pthreadHandle)
{
ASSERT(!identifierByPthreadHandle(pthreadHandle));
Here is what happens: A thread that is not created by WTF::CreateThread is
calling currentThread() in hope to get a ThreadIdentifier. It doesn't have
it so we create it and put into ThreadMap. Normally, WTF threads call
WTF::detachThread() that removes the ThreadIdentifier from the map. The
'other' threads do not do so - so the TheradIdentifier remains in the map.
On OSX, pthreads reuse system handles when one thread terminates and
another starts... That easily leads to threads that run sequentially to have
the same handle, and the same ThreadIdentifier - since it is still in the
threadMap, which makes currentThread() kind of useless since it returns the
same id for different threads, the very thing the threadMap is tryign to
avoid.
I'm thinking about changing the implementation to stop auto-register
non-WTF threads.
Wouldn't this break binary compatibility?
If you mean nightly builds, OSX Safari runs fine with this. On Windows it's
going to be ok because we use OS-supplied ThreadIdentifiers there.
Does pthreads have any facility to register a callback that's called on
thread shutdown? Could we use some sort of thread local storage to keep
track of whether that thread has been auto-registered yet?
I think I see what you mean. I tried to figure out if it is possible. There
is a callback invoked on destruction of a thread-specific slot... Perhaps it
can be used to un-register the thread if we add a thread-specific slot to
all incoming threads. The problem with those is that they are called in
unspecified order so another thread-specific destructor could re-register a
thread again, by calling currentThread(). Perhaps there is a way to do this
cleanly, it escapes me at the moment...
Maybe all non-registered threads could just use a default thread identifier
and some sort of warning message could be logged the first time this
happens?
Most usages of currentThread() are like this:
ASSERT(m_myThreadId == currentThread());
Basically, they verify that the object is called on the same thread as
created... Returning same identifier for different threads satisfies this
check even if the treads are different. If currentThread() returned the
different identifier each time in case of un-registered thread, it would
force the developer to either use WTF::createThread or WTF::registerThread.
Instead, lets add a new function, WTF::registerThread() that would
establish the ThreadIdentifier for a thread not created by WTF::createThread
- and assert in currentThread() if the current thread is unknown to WTF.
This way, we could find all the cases of such threads and equip them with
registerThread()/detachThread() pair that will keep the thread map in a good
state.
The currentThread() would look like this:
ThreadIdentifier currentThread()
{
pthread_t currentThread = pthread_self();
if (ThreadIdentifier id = identifierByPthreadHandle(currentThread))
return id;
ASSERT_NOT_REACHED();
// Either the thread is not created by WTF::CreateThread() or
registered by WTF::registerThread(), or we are getting
// a call from thread-specific destructor after WTF::detachThread()
was called and ThreadIdentifier removed.
// Neither scenario permits reliable thread id tracking, so we can not
return a meaningful ThreadIdentifier here.
// Normally ThreadIdentifiers are compared so lets generate a fake
one-time ThreadIdentifier to fail comparison, if
// it is in fact done.
static ThreadIdentifier fakeId = minFakeIdentifierCount;
if (fakeId == maxFakeIdentifierCount)
fakeId = minFakeIdentifierCount;
return fakeId++;
}
What would you say? Any bad feelings about that?
Dmitry
___
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] Database in Worker context
On Thu, Dec 10, 2009 at 11:09 AM, Eric Uhrhane er...@chromium.org wrote: On Wed, Dec 9, 2009 at 6:55 PM, Dmitry Titov dim...@chromium.org wrote: Thanks for the link to the prototype code! If I understand it right and the DatabaseManager can not have any other relationship with ScriptExecutionContext but 1-1 and their lifetime is the same then it's not clear to me what benefit could be had by effectively splitting a class in two. The fact that DatabaseManager is RefCounted also hints that some other object could take ownership of it as well outside of lifetime of ScriptExecutionContext, but is this true? That's there because the DatabaseThread [and therefore the Database] can stick around for a bit after the ScriptExecutionContext is deleted if I make it non-refcounted. If I move the DatabaseManager parts into the ScriptExecutionContext, then I have to make sure that the SEC sticks around until after the Database and DatabaseThread have gone away. It feels that there is a new class that does not have a specific lifetime or relationship to other existing classes, as it is a mechanical part of some other class rather... I look at how m_document is used by current Database and it feels that if SEC had a databaseThread() accessor, then all other methods like addOpenDatabase etc could be part of DatabaseThread instead, with Database keeping a pointer to its DatabaseThread. What do you think about this? ScriptExecutionContext collects functionality common for Workers and Documents, and as such is a home for a few 'groups' of methods, like a few methods to deal with MessagePorts. MessagePort, in turn, has a raw pointer back to ScriptExecutionContext - so it's clear that MessagePorts do not outlive the SEC. Same pattern could be used for ScriptExecutionContext/Database, for consistency. It also simplifies design a bit - no need for a special refcounted manager class, and things like callOnJavaScriptThread could be replaced by SEC::postTask() which is already implemented. The point of CallOnJavascriptThread is that the JS thread is the Main Thread in the Document context, but [in Chromium's implementation] NOT in the Worker context. I needed a virtual method to distinguish between the two cases, since the Database code previously treated isMainThread as synonymous with isJavascriptThread. But of course that virtual method can be moved to Document and SEC instead of DDM and WDM. I understand the reason for callOnJavascriptThread... This is exactly as SEC::postTask is defined - it posts a task from any thread to the one which executes JavaScript code for a given SEC. So for Document it is the main thread, for Workers - the thread associated with WorkerThread. I think they are the same thing - you can just use postTask in place of callOnJavascriptThread. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WTF::currentThread() and non-WTF threads
Hi webkit-dev!
Trying to add ASSERTS to RefCounted objects (
https://bugs.webkit.org/show_bug.cgi?id=31639) I've added some more calls to
WTF::currentThread() and started to get a lot of assertions here:
static ThreadIdentifier establishIdentifierForPthreadHandle(pthread_t
pthreadHandle)
{
ASSERT(!identifierByPthreadHandle(pthreadHandle));
Here is what happens: A thread that is not created by WTF::CreateThread is
calling currentThread() in hope to get a ThreadIdentifier. It doesn't have
it so we create it and put into ThreadMap. Normally, WTF threads call
WTF::detachThread() that removes the ThreadIdentifier from the map. The
'other' threads do not do so - so the TheradIdentifier remains in the map.
On OSX, pthreads reuse system handles when one thread terminates and another
starts... That easily leads to threads that run sequentially to have the
same handle, and the same ThreadIdentifier - since it is still in the
threadMap, which makes currentThread() kind of useless since it returns the
same id for different threads, the very thing the threadMap is tryign to
avoid.
I'm thinking about changing the implementation to stop auto-register
non-WTF threads. Instead, lets add a new function, WTF::registerThread()
that would establish the ThreadIdentifier for a thread not created by
WTF::createThread - and assert in currentThread() if the current thread is
unknown to WTF. This way, we could find all the cases of such threads and
equip them with registerThread()/detachThread() pair that will keep the
thread map in a good state.
The currentThread() would look like this:
ThreadIdentifier currentThread()
{
pthread_t currentThread = pthread_self();
if (ThreadIdentifier id = identifierByPthreadHandle(currentThread))
return id;
ASSERT_NOT_REACHED();
// Either the thread is not created by WTF::CreateThread() or registered
by WTF::registerThread(), or we are getting
// a call from thread-specific destructor after WTF::detachThread() was
called and ThreadIdentifier removed.
// Neither scenario permits reliable thread id tracking, so we can not
return a meaningful ThreadIdentifier here.
// Normally ThreadIdentifiers are compared so lets generate a fake
one-time ThreadIdentifier to fail comparison, if
// it is in fact done.
static ThreadIdentifier fakeId = minFakeIdentifierCount;
if (fakeId == maxFakeIdentifierCount)
fakeId = minFakeIdentifierCount;
return fakeId++;
}
What would you say? Any bad feelings about that?
Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Database in Worker context
On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane er...@chromium.org wrote: I've pulled the database-related members out of Document and made a new class for them, DatabaseManager. An instance of that is owned by each ScriptExecutionContext. There are two flavors, DocumentDatabaseManager and WorkerDatabaseManager. They're not very different, but in a few cases it was necessary to distinguish between them I don't see your code, just generic thought: If those classes are small, then perhaps ScriptExecutionContext could absorb a couple of methods to deal with that? Some of them could be virtual and implemented differently on Document and WorkerContext. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Database in Worker context
Thanks for the link to the prototype code! If I understand it right and the DatabaseManager can not have any other relationship with ScriptExecutionContext but 1-1 and their lifetime is the same then it's not clear to me what benefit could be had by effectively splitting a class in two. The fact that DatabaseManager is RefCounted also hints that some other object could take ownership of it as well outside of lifetime of ScriptExecutionContext, but is this true? ScriptExecutionContext collects functionality common for Workers and Documents, and as such is a home for a few 'groups' of methods, like a few methods to deal with MessagePorts. MessagePort, in turn, has a raw pointer back to ScriptExecutionContext - so it's clear that MessagePorts do not outlive the SEC. Same pattern could be used for ScriptExecutionContext/Database, for consistency. It also simplifies design a bit - no need for a special refcounted manager class, and things like callOnJavaScriptThread could be replaced by SEC::postTask() which is already implemented. Dmitry On Wed, Dec 9, 2009 at 5:21 PM, Eric Uhrhane er...@chromium.org wrote: On Wed, Dec 9, 2009 at 4:11 PM, Dmitry Titov dim...@chromium.org wrote: On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane er...@chromium.org wrote: I've pulled the database-related members out of Document and made a new class for them, DatabaseManager. An instance of that is owned by each ScriptExecutionContext. There are two flavors, DocumentDatabaseManager and WorkerDatabaseManager. They're not very different, but in a few cases it was necessary to distinguish between them I don't see your code, just generic thought: If those classes are small, then perhaps ScriptExecutionContext could absorb a couple of methods to deal with that? Some of them could be virtual and implemented differently on Document and WorkerContext. Dmitry You don't see the code because I sent this as an early warning--there's nothing checked in yet. The classes aren't huge, and in fact most of the code was in Document before, but given that it's all to do with a separable concept [the Database], I thought it nicer to pull it out. Let's see...DatabaseManger.cpp is 172 lines [including copyright headers, etc.] and the header is 107. Seems like a lot to sprinkle through ScriptExecutionContext, Database, and WorkerContext. You can take a look at my current code [where I'm backing it up--this won't actually be sent for review from this repository] at http://codereview.chromium.org/401016/show [mostly storage + v8 bindings] and http://codereview.chromium.org/464018/show [mostly Chrome browser process stuff] and see what you think. Thanks, Eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SharedScript: next steps and result of offline discussion.
Hi WebKit, The recent discussion indicated there is a feeling that SharedScript functionality can be achieved by other means that do not require adding new big APIs: changing iframe a bit (so it's internals survive reparenting into another document) and adding single getWindowByName() API. Ian Hickson proposed this idea noting that nothing in the spec prevents iframe from staying alive over the reparenting. Some folks from Google met with folks from Apple to discuss and it appears there is a consensus that we shall remove initial code for SharedScript and instead implement changes for iframe and getWindowByFrame(). This will not cause new API and hopefully won't cause compatibility issues since the only scenario that will behave differently is reparenting of the iframe between documents that is hopefully a rare thing. Perhaps more discussion will be needed to nail details on those. Separately (or related?), we discussed SharedWorkers and the way XHR works in them. It seems a good idea to investigate a shadow document' solution (as Chrome does for worker processes) when a dummy document is created and used to load resources on behalf of the worker. Also we'll try to fix couple of bugs that prevent Workers to be reliable enough. Thanks a lot to all who chimed in and helped to arrive to a good solution to the same issues that SharedScript was trying to solve! :-) Dmitry Titov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharableScriptContext [was: GlobalScript in WebKit]
On Mon, Nov 30, 2009 at 10:24 PM, Oliver Hunt oli...@apple.com wrote:
All that said, Darin, Maciej and I were discussing this on IRC earlier and
it would seem that simply adding getWindowByName (or some such) would gain a
very large amount of the behaviour desired in the {Shared,
Global}Script[Context] concept.
Got to the colloquy transcript of this. I think the proposal there is to
implement getWindowByName() and not to have SharedScriptContext object at
all, rather emulate it by passing around a JS object which would be used to
share things. The argument was made that this will reduce the API explosion
and be less work in WebKit.
However, I'd need to understand how the following would work:
- it's not clear how to load script (the code that is supposed to be
shared). The apps today don't just load the whole code in a single script,
they split the script code in pieces and use script tag injection or async
XHR + eval. All of that is defined with reliance on underlying global scope
object which can not be relied upon in the proposed case. Unless JS has some
way to introduce a global scope other then default window... It seems that
'eval' method of progressive script loading breaks.
- running a JS method on a shared JS object depends on global scope used in
context of the call. In case of cross-context calls it can be very confusing
for the developers to understand which context is being used, and I think we
have some bugs in this area too (at least there are a few FIXME sprinkled
around). Having a global scope object associated with the shared script
context makes things easier to use and potentially less buggy. Not sure how
much this is the issue though.
- there were already noted issues with timers, XHR, WebSockets, (as well as
Database, Notifications etc) that simply get killed internally when their
native window closes - there is no exceptions thrown or callbacks called.
The JS wrappers that are still alive but zombied remain, but to be able to
write JS code that correctly recovers don't we need to define some behavior
of those things in case their 'native context' dies? I guess the solution is
to host those in SharedWorker, which was already noted as being not always
desirable.
I agree with desire to reduce the new APIs and this is essentially reducing
it to 0. In particular cases we currently have (GMail and Chat windows)
windows are opened via window.open() so technically we don't even need
getWindowByName() to try this approach. But, will it work? Not sure, for the
reasons above.
Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
We could name a couple of big ones (GMail was already mentioned before), they already have designs ready to go into test as soon as they get SharedScript in a dev build. If there was no desire from actual app developer teams for SharedScript, we would not have the reason to continue with it long time ago. That also pretty much means if we won't do SharedScript, we'll need to explore other opportunities toward efficient sharing of code and data which does not make people to write a multithreaded UI as SharedWorker solution would do. We have practically zero positive response to SharedWorkers being used this way. Granted, this is just one company but the limited unscientific poll kind of shows the direction... On Mon, Nov 30, 2009 at 1:58 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 30, 2009 at 1:54 PM, Geoffrey Garen gga...@apple.com wrote: There are a lot of people inside Google that have a lot of experience with web standards, browsers, and web apps that seem to think this is useful and worth the effort to experiment with it. Who exactly inside Google is waiting to build a new service, feature, or experiment using SharedScript? I don't think we can or should have to say specifically, but several major apps with millions of users. ___ 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] GlobalScript in WebKit
I don't think it's correct to say that SharedWorkers are not useful and we need a SharedScript instead. They are different things and can address different use cases. For example, SharedWorker is great to make sure there is only one 'app instance' running - exactly because it is shared inter-process, it can be used as a inter-process synchronization primitive to control how many app instances are opened. SharedScript is a container for data and code shared between pages that comprise a web application and normally run in the same process. As in native apps, whether or not multiple instances of the app can run at the same time depends on the author of the app, and can be done either way. Multi-process browsers are bringing more complexity (and benefits). Not all technical issues http://www.chromium.org/developers/design-documents/process-modelsare completely resolved in Chrome's implementation, and we might need (or not) some mechanism of saying that a bunch of pages form an application and should share a process. Right now, it's unclear if such mechanism even needed though. I agreed with you to remove the implementation details from the doc because indeed they do not belong there. Not that they are not existing. For example, the fact that in Chrome SharedWorkers are indeed inter-process theoretically could be different. WebWorkers spec does not specify where and how to look for instances of SharedWorkers, although it implies some useful degree of sharing. The fact that in Chrome they are shared across all processes is a detail of Chrome implementation. Dmitry On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen gga...@apple.com wrote: Just a note: In Chrome, a SharedWorker is reachable from any WebKit process, whereas a SharedScript would only be reachable within a WebKit process. This is an interesting distinction, and I can imagine some use cases for SharedWorker that SharedScript could not address. (This distinction arises because we did not want to build a script proxy between WebKit processes as that would be quite costly.) For example, suppose you wanted to have only one instance of a web app responsible for manipulating a database or communicating with a server. There's no guarantee that multiple instances of a web app would all run in the same WebKit process. Actually, I objected to that distinction, and it has been removed from the specification. You can find the discussion here: https://bugs.webkit.org/show_bug.cgi?id=31317. And the specification here: http://docs.google.com/View?id=dxv3cth_4gvggh3gh. I'm concerned that a lot of Chrome engineers are speaking for Google, but they don't really have their stories straight. First, a group of Chrome engineers said that Google needed SharedWorker, so it was implemented in WebKit. Now, a group of Chrome engineers says Google can't use SharedWorker, and needs SharedScript instead. So, we're gearing up to implement that. Meanwhile, not all Chrome engineers agree about what SharedWorker is or why it is that way, and we can reasonably assume that the actual Google engineers who have asked for these technologies disagree even more. It's OK to disagree and hash out ideas. But it's a little weird to try to dictate the direction of WebKit in the name of Google and several major apps with millions of users, when that standard seems to blow whichever way the wind goes. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote: By the way, we could enable the SharedScript programming model at much lower WebKit-level implementation cost and with much less API surface as follows: - Allow Window to be passed via the structured clone algorithm over a MessageChannel, but it throws on all access if the recipient is not same-origin, in the same thread, and eligible for synchronous calls (i.e. in the same process). I believe this would allow SharedScript to be implemented in JavaScript. Essentially you'd use a SharedWorker to coordinate and elect a leader Window within each same-process group, which could then create a JavaScript object which it vends to all other Windows. The object does not get GC'd until all the referencing windows go away. Yep, a variants of this were proposed... One difficulty with this is that while JS object is kept alive, the interesting objects like timers, XHR, WebSockets die once leader Window is closed. Plus, the leader [re]election algorithm should be implemented. It is not impossible to keep track of enough things to fix up the context, but it is way too difficult and error-prone. It sounds like by making it easier with SharedScript we'd remove the burden of those implementations from many web developers. Just connect to it and it provides stable JS context for things to run in. If we go with this, I believe we'll need to follow up with things like making XHR work even if page created it was closed... It might end up being essentially the same as SharedScript itself. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
What I meant was it would be nice, for the sake of discussion, to share the experience of real life applications that used SharedWorkers or inter-window communications for sharing of significant portions of code and data. Google apps may be a partial example but it is a real life example of concrete issues with proposed solution that sounds pretty generic and useful for other web apps. It is only prudent to take their feedback rather then replace it with our own theories about future of the web. No doubt this is a new mechanism and it's good to question it, since it has costs even as experimental API. Gut feelings vary, some app devs say they need it to solve real issues, we dont hear from other app devs who were facing similar issues and solved it differently. Seems there is no strong argument to kill it nor bless it. Why don't make it experimental and see? If it was possible to implement it in extension or plugin, we would run it as another Gears-like experiment, but it can not be done in a plugin... I believe there could be good arguments that simply didn't surface yet, and hope to hear them. Dmitry. On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting pkast...@google.com wrote: On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov dim...@chromium.org wrote: BTW, could you tell what's the 'course' that would be reverted? Meaning, before we decide that SharedWorkers and inter-window communication are insufficient, and a further proposal should be entertained by the standards community. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript in WebKit
Hi Sam! Thanks a lot for sharing your perspective! I really wish your reply had, in addition to the statement of the opinion, an argument or just more explanation of why you think so. I think we covered SharedWorkers and inter-window communication in the previous discussions and in the design doc. BTW, could you tell what's the 'course' that would be reverted? Dmitry On Wed, Nov 25, 2009 at 8:30 PM, Sam Weinig sam.wei...@gmail.com wrote: Hi Dmitry, As I have noted to others on the Chrome team, I do not think this is good idea and I don't think we should have it in WebKit. It adds extra complexity to WebKit and gives little beyond what is possible using inter-window communication and SharedWorkers. I think we need to give more time for large applications to adopt designs around workers before we reverse course, at which point, we should again discuss this in the standards community. -Sam On Thu, Nov 19, 2009 at 10:35 PM, Dmitry Titov dim...@chromium.org wrote: Hi webkit! I'm starting to work on actual implementation of GlobalScript experimental API and started to post patches (hopefully in reviewable portions). There is an uber-bug which has plan of implementation. The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC and v8 bindings (first with JSC because at the moment JSC bindings are easier to work with and I'd wish WebKit not to have 1-engine-only features ever). I'd be glad to know if there are suggestions, ideas or concerns of any kind... For example, if there is no interest in JSC bindings, it can be hard to get them reviewed by someone who knows them well. It'd be better to know that earlier. Thanks! Dmitry ___ 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] GlobalScript in WebKit
Hi webkit! I'm starting to work on actual implementation of GlobalScript experimental API http://docs.google.com/View?id=dxv3cth_2rnj9wffz and started to post patches (hopefully in reviewable portions). There is an uber-bughttps://bugs.webkit.org/show_bug.cgi?id=31317which has plan of implementation. The current plan is to get it in under ENABLE_GLOBAL_SCRIPT, with both JSC and v8 bindings (first with JSC because at the moment JSC bindings are easier to work with and I'd wish WebKit not to have 1-engine-only features ever). I'd be glad to know if there are suggestions, ideas or concerns of any kind... For example, if there is no interest in JSC bindings, it can be hard to get them reviewed by someone who knows them well. It'd be better to know that earlier. Thanks! Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] ThreadIdentifier abstraction is inefficient
On Thu, Oct 29, 2009 at 3:10 PM, Anton Muhin ant...@chromium.org wrote: ens, Somewhat aside from ThreadIdentifier. Actually, at least for now, there should be no invocations of WTF::currentThread() at least for the renderer---everything should run in the same thread. That sounds right. Same for Chromium Worker processes. Some time ago we tried to run workers in the same process as renderer, or several workers in the Worker process using v8 locking. It didn't work well so we abandoned the idea. Seems like some good cleanup could help, nothing is as fast as not running the code! :-) As for previous attempt to fix the issue, there were 2 main concerns (to recap): - pthread_t is reused by some OSes between threads so comparing thread ids may give false matches in case we just use pthread_t as TheradIdentifier. - Safari apparently uses WTF directly from JSC and changing binary interface and especially subtle protocol details will likely break nightly builds. Optimally, someone with visibility into both codebases could fix this with more confidence. Alternatively, perhaps such services as threading could be provided by the embedder via WebKit API rather then implemented in WTF - since embedders need access to the same time/thread services as the rest of WebKit. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Runtime setting for incomplete features
On Mon, Oct 5, 2009 at 9:48 PM, Sam Weinig sam.wei...@gmail.com wrote: I would still very much like a good solution to runtime enabling/disabling features in the bindings as I think this would be a useful addition to the webkit arsenal and I am curious why it is thought that doing it right will be prohibitively expensive (it may very well be, I just don't know why that is). This is a good question, I don't see also why it will be very difficult... It seems most of the features we are talking about are exposed off window object that already has custom getters. Also, if it can be assumed that the flags don't change during lifetime of the browser process (which is true for Chromium-like command-line flags) then it is not needed to reset script state and caches on change. It might be not a very complex change... Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] window.open issues in DRT?
One (quite old) change - http://trac.webkit.org/changeset/25793 - has changed tests using window.open to use iframes instead, apparently because of some difficulty in DRT with closing windows... I'm finding myself creating tests using window.open(). Can anybody remember if those difficulties were fixed or what they are? The change does not explain what was the issue... Thanks! Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript API.
This actually displays one of the issues i have with global script as a concept, you are basically just doingiframe src=.../.. And that gives you a context that achieves almost everything the global script concept gives you. People keep saying that this is no better than a new window or an iframe because you can script those synchronously across pages, but that totally misses the point. The the frame/script/window survives when it's parent page is closed if there's another page pointing to it and, in some versions of this proposal, it survives same-origin page navigations. That isn't true of iframes or windows and is exactly what makes these useful. This is exactly right, the most interesting aspect is its lifetime that makes it a nice place to call 'the application'. It can keep the app state while pages navigate between each other, making browser history and page cache just work. And it can make windows independent of each other without loading the whole app in each of them... There was an interesting presentationhttp://en.oreilly.com/velocity2009/public/schedule/detail/7611from Facebook folks at O'Reilly Velocity conference (pdf slides here http://figushki.com/test/FacebookFrontEnd_Velocity2009.pdf) where they describe 'quicklings' - the elaborate way to avoid full page loads. Also they try to cache as much as possible in the 'live' form in memory - so they can keep those fast caches up to date. This is similar to what many applications are doing today - trying to keep a single 'main' page alive and inventing their incarnations of navigation and history. Global Script could be useful there as a replacement for those ad-hoc mechanisms. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] GlobalScript API.
Hi WebKit-dev, I'm hoping to get your advice on Global Script proposal and how to start implementing it as an 'experimental API' since it's not standardized yet. As part of work on Workers in WebKit and Chromium, we discussed them with our web application folks (mostly gmail). We came to the idea that in addition to workers, they need a shared script context which runs on the same UI thread and directly scriptable. Our previous take (with an invisible window running all the time in the background) was not that fruitful but it indicated the way to go. We are thankful to the members of the whatwg community for the detailed threat analysis of 'permanently running invisible pages', it helped very much. Not right away but it was absorbed :-) Current proposal reflects realization that there is a less-powerful way to achieve the same benefits. I'm looking for a way to implement it as an experimental API in WebKit and Chromium. I'm thinking it can go the similar way as webkitNotifications - surrounded by ENABLE(GLOBAL_SCRIPT) and prefixed with 'webkit' to keep the difference. I'd appreciate much your advice on the whole API and on the way to bring it into WebKit. Here is a link to the whatwg thread, with the proposal and use cases: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022113.html Here is an actual API: --- Page-level API var globalScript = new webkitGlobalScript(name, url, loadHandler, errorHandler); This returns a global scope object for the named Global Script. If one does not exist yet, creates a new one. The globalScript is sharing same process and same thread as the page running the constructor and is operational right away. No synchronization is necessary. Parameters: name - string identifying the global script. Scoped to the orogin. url - the JS resource to load, if it was not yet loaded. If the Global Script is already loaded but from a different url - the error is raised. laodHandler - a function called asynchronously when the script is loaded (or if it was already loaded by another page) errorHandler - handler for loading errors, like violation of same-origin policy or network error The GlobalScript would create its own ScriptExecutionContext-derived context if it was not yet created, and start to load the script into it. Once the script is loaded, it is evaluated in the global scope of the Global Script and loadHandlers are executed. Other pages that create a Global Script with the same name in the same origin would get the same object back. The globalScript object returned from the constructor can be immediately used to set/retrieve properties and event handlers on it. API exposed to Global Script (on its global scope object) - Timers - XHR - Navigator - localStorage - Database - Workers - Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] GlobalScript API.
Ian also said (and I agree with him) that experimental implementation is needed. In fact if he added it to HTML5 already I'd be very surprised. For example, the notifications were removed from HTML5 because it was not clear to the point of writing the spec that they are even needed (as Ian said also). A lot of HTML5 is there because there were Gears with real-life experience. It's hard to see if any web mechanism will prove it viability purely theoretically. So all we are trying to do is take the feedback from app developers, produce a proposal, discuss it in the community to refine it, produce implementation and see how it goes so it can be included into HTML x at some point. It might not stand the test of time and not be standardized at the end, or it might influence some other idea - who knows? Nobody is 'pushing ahead' :-) Dmitry On Mon, Aug 31, 2009 at 6:18 PM, Peter Kasting pkast...@google.com wrote: On Mon, Aug 31, 2009 at 6:09 PM, Dmitry Titov dim...@chromium.org wrote: I'm hoping to get your advice on Global Script proposal and how to start implementing it as an 'experimental API' since it's not standardized yet. That sounds a little optimistic when so far the feedback from Hixie is I haven't added the Global Script Object proposal to HTML5. ... I really don't think it is the direction we should be taking the platform in. I realize that there have been subsequent comments objecting to that viewpoint, I'm just saying that pushing boldly ahead seems... early. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] I *HATE* CHANGELOGS!!!
Arguably a text file is the simplest and most reliable way to keep a log over time and across tools and platforms. Things happen to databases (bugzilla!) more often then to plain text files. It seems there are ways to reduce the merging hassle using better tools/process. +1 to having a single ChangeLog though! Also, this can be done independently from other improvements. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
I think there is still little clarity around the appcache behavior (dimich: are you bring over your shadow frame concept to webkit?). I'm wondering about bringing the 'shadow frame' technique to webcore too? If needs be :-) Just to explain what is meant by 'shadow frame' (I'm not sure it was discussed in webkit-dev beore): to provide access to FrameLoader in Chrome's Worker process (which loads WebKit but doesn't load any html, just creates a worker out of JS string), we create a WebView and load it from a (url, encoding, mimtype, data) source with empty data and the worker's url. This creates a frame with a an empty document but with a right origin and encoding. This makes it possible to create a ThreadableLoader (and underlying DocumentThreadableLoader) w/o aceess to the original worker's parent. This loader is used to implement XHR and importScripts in Chrome workers. Oriinally a Darin Fisher's idea, it was implemented as alternative to rollign out a new frame-less loader. Shared workers can use the same approach since they can not forever hold the ref to the 'creating' document. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Expected behavior of Mutex.lock()
Then perhaps all implementations could ASSERT in debug on mutex reentrancy to help discover where differences in behavior are accidentally 'used' (a stuck thread may sometimes mask some other issues). It's not good to have this kind of differences in 'cross-platform' code, sooner or later it'll cause very cryptic bugs, especially since developers with Windows background take reentrancy of critical section for granted. Dmitry On Tue, Jun 9, 2009 at 11:34 AM, Jeremy Orlow jor...@chromium.org wrote: I actually had exact the same question (but never got around to asking it). Given that pthreads' implementation is more strict, it'd seem like mutexes are not supposed to be reentrant. Maybe the windows version should ASSERT on reentrancy when in debug mode? On Tue, Jun 9, 2009 at 11:09 AM, Drew Wilson atwil...@google.com wrote: Any insights here? I'd be happy to add some documentation to Mutex if someone can verify what the intended behavior is... -atw sending emails to webkit-dev during WWDC is probably futile, I know :) On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson atwil...@google.com wrote: I can't seem to find any documentation as to what the expected behavior of Mutex.lock() is with regard to calling lock() recursively on the same thread. Looking at the pthreads implementation, it appears that when we create the mutex we pass null as the attributes, which gives us the default behavior (not re-entrant). The Windows implementation uses EnterCriticalSection which *is* re-entrant. I'm assuming that the pthreads implementation is the correct one (calling Mutex.lock() twice on the same mutex on a single thread should deadlock the thread) but I wanted to verify this since the implementations seem to vary. -atw ___ 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Multithread issue
WebKit uses thread-specific data in quite a few cases so objects in general expect to be created, used and destroyed on the same thread. One of such examples are timers, frequently used as deferred tasks. Creating a view and loading a url into it likely creates one or more of such timers whihc are stored in thread-specific list. So the code verifies that we are still accessing the thread-specific list on the same thread on which we were creating the timer. Can you create view on the same thread where gtk_main is called? Dmitry On Wed, May 27, 2009 at 5:17 AM, Matt Bockt bocktm...@gmail.com wrote: Hi everybody, I'm new to WebKit and I'm developing a C++ application that uses the WebKit browser. It runs on Fedora10, kernel 2.6.27.5-117.fc10.i686. The WebKit version I'm using is the r44111. Here is my problem : I'm creating a new web view in the main thread, say, thread A. The webview is then attached to a gtk_window as it's made in the GtkLauncher exemple. Then webkit_web_view_load_uri() is called, always in thread A. Finally, the gtk_main() function is called in another thread, say thread B. And it crashes with the following trace : ASSERTION FAILED: m_thread == currentThread() (WebCore/platform/Timer.cpp:206 bool WebCore::TimerBase::isActive() const) I experience this problem with the webkit r44111 and r43808, but not with r38297. I noticed that there must have been a modification in the thread management between the builds r38297 and r43808 since g_threads must be initialized. But I can't figure out why it doesn't work. Any suggestions or specific rules to follow about multi-threading, gtk and webkit ? Thank you for your help. -- matt ___ 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] How to create a test for a missing layout update bug?
Hi WebKit, I hope you can help me with ideas on how to create a test for the bug where layout update does not happen (https://bugs.webkit.org/show_bug.cgi?id=24453 ). The bug is caused by timeout code using Document::updateRendering() instead of Document::updateDocumentsRendering() so it can miss the actually changed document. However, many things trigger layout so any attempt to dump the render tree, use layoutTestController::display() etc do not 'catch' the buggy behavior since all of them trigger layout. I have a test that is based on extending layoutTestController to expose FrameView::needsLayout() but it does not feel right to me to expose internals. Perhaps anybody had a need to write a test for missing layout update before.. I would appreciate all possible ideas about it! Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Using LGPL-derived source in one of the wtf files.
Hi, There was an IRC discussion about https://bugs.webkit.org/show_bug.cgi?id=23373, and there was no clear solution.. In the proposed patch the ThreadingWin.cpp would contain 2 licenses - standard WebKit one and a copy of Pthread-win32 license (LGPL). The latter is there because the code for ThreadCondition is derived from the sources of that library (removing the need to pull in the whole library for 50 lines of code). Does this idea look acceptable? Can we use LGPL'ed source this way and how should we go about the license if we can? Thanks, Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Change WTF::ThreadCondition::timedWait to use absolute time?
Good point. The double as used in SystemTime.h looks right indeed. On Tue, Dec 30, 2008 at 10:31 PM, Darin Adler da...@apple.com wrote: On Dec 30, 2008, at 6:21 PM, Dmitry Titov wrote: bool ThreadCondition::timedWait(Mutex mutex, const struct timespec *timeoutTime) It seems OK, roughly speaking, but I don't think that will achieve the platform independence goals of the Threading.h header. The type timespec is not necessarily a suitable one for use on all the different platforms we support. So even if it's an absolute time, we might want to use a double rather than a timespec. But we'd probably need to move currentTime from WebCore/platform/SystemTime.h to somewhere in JavaScriptCore/wtf to serve as a timebase. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Change WTF::ThreadCondition::timedWait to use absolute time?
For worker implementation of run loop, I am looking to implement
MessageQueue::waitForMessageWithTimeout(), where timeout would be computed
from the the JS timer with nearest expiration. I am looking at using
WTF::ThreadCondition::timedWait for implementation but it seems it is not
implemented right... Before trying to send a patch, I'd like to ask here to
validate the idea.
It is defined with 'secondsToWait':
bool ThreadCondition::timedWait(Mutex mutex, double secondsToWait)
while a corresponding pthread function takes absolute time:
int pthread_cond_timedwait(pthread_cond_t *, pthread_mutex_t *, const
struct timespec *);
The reason pthread function takes abs time is because pthread's function
can return 'spuriously'. I think the reason is that most implementation lack
the atomic wake up and re-acquire the mutex operation, so the conditions
can change between waking up and re-acquiring the mutex - and the wait can
return while in fact it should have not. Here is a piece of pthread doc (
https://computing.llnl.gov/tutorials/pthreads/man/pthread_cond_timedwait.txt
):
When using condition variables there is always a Boolean
predicate involving
shared variables associated with each condition wait that is
true if the thread
should proceed. Spurious wakeups from the
pthread_cond_timedwait() or
pthread_cond_wait() functions may occur. Since the return from
pthread_cond_timed-
wait() or pthread_cond_wait() does not imply anything about
the value of this
predicate, the predicate should be re-evaluated upon such return.
That means the waiting should always be done in a loop, checking if
the thread can actually proceed and if not, call wait function again,
like here:
bool MessageQueue::waitForMessage()
{
MutexLocker lock(m_mutex);
while (m_queue.isEmpty())
m_condition.wait(m_mutex);
.. consume message ...
}
In case of timed wait it means the absolute time should be computed
before such loop, and it explains why pthreads have timed wait
function with absolute time as a parameter. That means WTF timedWait
method should change prototype to take absolute time:
bool ThreadCondition::timedWait(Mutex mutex, const struct timespec
*timeoutTime)
Then it's possible to implement blocking
MessageQueue::waitForMessageWithTimeout() to return exactly after
specified timeout or with a message.
Ok to change?
Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timer callback and 'this' object
Thanks Sam,
I've sent a patch with a test.
Dmitry
On Mon, Dec 1, 2008 at 7:23 PM, Sam Weinig [EMAIL PROTECTED] wrote:
Hi Dmitry,
The first example using a closure executes in the parent scope because
functions execute in lexical scope regardless of where they are called from,
capturing variables as required. The string version is simply executed as a
program by the caller and has no knowledge of the scope in which it was
declared. This is a bit strange, but follows the conventions of the
language. As for the test, tests are always welcomed, especially for odd
edges like this.
-Sam
On Mon, Dec 1, 2008 at 8:08 PM, Dmitry Titov [EMAIL PROTECTED] wrote:
Hi webkit-dev,
I'm looking at JS timeout code and found a callback behavior that seems
strange. Not sure if it is intentional.
If timeout is set on a 'window' object from another frame and timeout
callback is specified as a JS string, it is executed inside the frame...
So the context of execution is different depending how the callback is
specified.
Here is html (also attached) that loads an empty IFRAME and sets 2
timeouts on that iframe's window - as a JS closure and as JS string. In
former case, the callback runs in the main page (expected, since the JS
closure 'captures' the context in which it is defined), in the latter-
inside iframe (a bit weird?). So the text goes in both body elements.
Is there a reason why JS string is evaluated in the inner context of the
iframe? Would a test verifying this behavior be a good thing? Curiously, IE
and FF behave the same way.
html
script
function test() {
// Get the iframe's window.
var iframeWindow = window.frames[testIframe];
// setTimeout with a closure as callback.
iframeWindow.setTimeout(
function() {
if (!document.body)
document.write('body/body');
document.body.appendChild(document.createTextNode('Timer 1
fired.'));}, 1);
// setTimeout with a JS string containing similar code.
iframeWindow.setTimeout(
if (!document.body) +
document.write('body/body'); +
document.body.appendChild(document.createTextNode('Timer 2
fired.'));, 1);
}
/script
body onLoad=test();
iframe src=about:blank id=testIframe/iframe
/body
/html
Thanks,
Dmitry
___
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] Timer callback and 'this' object
Hi webkit-dev,
I'm looking at JS timeout code and found a callback behavior that seems
strange. Not sure if it is intentional.
If timeout is set on a 'window' object from another frame and timeout
callback is specified as a JS string, it is executed inside the frame...
So the context of execution is different depending how the callback is
specified.
Here is html (also attached) that loads an empty IFRAME and sets 2 timeouts
on that iframe's window - as a JS closure and as JS string. In former case,
the callback runs in the main page (expected, since the JS closure
'captures' the context in which it is defined), in the latter- inside iframe
(a bit weird?). So the text goes in both body elements.
Is there a reason why JS string is evaluated in the inner context of the
iframe? Would a test verifying this behavior be a good thing? Curiously, IE
and FF behave the same way.
html
script
function test() {
// Get the iframe's window.
var iframeWindow = window.frames[testIframe];
// setTimeout with a closure as callback.
iframeWindow.setTimeout(
function() {
if (!document.body)
document.write('body/body');
document.body.appendChild(document.createTextNode('Timer 1
fired.'));}, 1);
// setTimeout with a JS string containing similar code.
iframeWindow.setTimeout(
if (!document.body) +
document.write('body/body'); +
document.body.appendChild(document.createTextNode('Timer 2
fired.'));, 1);
}
/script
body onLoad=test();
iframe src=about:blank id=testIframe/iframe
/body
/html
Thanks,
Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposed Timer API
Since our systems are not real-time, saying 'hi-res timer' and 'event
dispatching' together may need some clarification.
Lets say we set delay=0.001 - but not every system can guarantee that the
timer event will fire at precise 1 ms interval. So it can skip a bit or
fire at longer delay, then continue at 1 and so on. Some systems may skip
more then a bit :-) That's why popular way to implement animations is to
request high frequency callback and query hi-res timer from the handler for
actual advance calculation...
The spec could explicitly point that out ('delay' - 'delayAtLeast' ?), and
perhaps recommend to use Date() in the event handler to see what is the
actual time of firing, or have an 'eventTime' property on an Event object.
On a separate note, it almost feels that just adding
invokeAsSoonAsPossible(handler) that is equivalent to unclamped
setTimeout(..., 0) could be all that's needed.
Dmitry
On Wed, Oct 1, 2008 at 9:59 AM, Justin Haygood [EMAIL PROTECTED] wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maciej
Stachowiak
Sent: Wednesday, October 01, 2008 1:02 PM
To: Darin Adler
Cc: WebKit Development
Subject: Re: [webkit-dev] Proposed Timer API
On Oct 1, 2008, at 9:58 AM, Darin Adler wrote:
On Oct 1, 2008, at 9:16 AM, Mike Belshe wrote:
If you're going to propose a new API designed for hi-res timers, it
ought to use units of microseconds instead of milliseconds.
Or units of seconds, perhaps? Since JavaScript numbers are already
floating point.
That's what I would propose. Then browsers can offer greater precision
in the future without having to redesign the API.
---
Updating now. Units of seconds. Precisision is browser defined, but will be
higher precision (or same precision) as setInterval/setTimeout.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
--
Dmitry
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
