[webkit-dev] How to build Webkit GTK on macos
From http://trac.webkit.org/wiki/BuildingGtk, it said i need to install ATK Cairo cURL fontconfig freetype2 gettext gtk+ libjpeg libpng libtiff libxml2 libxslt pango SQLite My question is how to install these packages on Macos so that i can compile Webkit gtk on Macos? Thank you. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] link-following feature for our new webkit browser.
a href=javascript:alert(0)link/a scriptwindow.location = document.links[0].href;/script Can confirm now that this works indeed. But still, some stuff does not work, like: a href=# onclick=return showcover(false);/a Further, it would be nice to be able to select/click form elements like checkboxes or textfields with this. Is there no way to fire a simulated click event on any possible element? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How to build Webkit GTK on macos
Maybe you need MacPorts http://www.macports.org/. Regards James Su On Wed, May 6, 2009 at 2:27 PM, Lucius Fox lucius.fo...@gmail.com wrote: From http://trac.webkit.org/wiki/BuildingGtk, it said i need to install ATK Cairo cURL fontconfig freetype2 gettext gtk+ libjpeg libpng libtiff libxml2 libxslt pango SQLite My question is how to install these packages on Macos so that i can compile Webkit gtk on Macos? Thank you. ___ 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] Problem with building WebKit
Hello Adam, I tried to build WebKit using the latest version and I see that the JavaScriptCoreGenerated without errors other than the xcopy error: Output Window Performing Makefile project actions xcopy /y/d/e/i ..\..\..\WebKitLibraries\win\tools E:\cygwin\home\Seby\WebKit\WebKitLibraries\win\tools Cannot perform a cyclic copy 0 File(s) copied touch E:\Build\buildfailed - - - - - - logs omitted - - - - - - Results Build log was saved at file://E:\Build\obj\JavaScriptCoreGenerated\Release\BuildLog.htm JavaScriptCoreGenerated - 0 error(s), 0 warning(s) And the second one (record-memory-win) failed w/ the link usage error as shown below: Output Window Compiling... main.cpp Linking... link: extra operand `/ERRORREPORT:QUEUE' Try `link --help' for more information. Project : error PRJ0002 : Error result 1 returned from 'E:\cygwin\bin\link.exe'. Results Build log was saved at file://E:\Build\obj\record-memory-win\Release\BuildLog.htm record-memory-win - 1 error(s), 0 warning(s) The thrid one (WTF) was successful showing the below Result: Results Build log was saved at file://E:\Build\obj\WTF\Release\BuildLog.htm WTF - 0 error(s), 0 warning(s) And again the link error on JavaScriptCore Performing Pre-Link Event... Linking... link: missing operand after `ÿþ/' Try `link --help' for more information. Project : error PRJ0002 : Error result 1 returned from 'E:\cygwin\bin\link.exe'. Project : warning PRJ0018 : The following environment variables were not found: $(PRODUCTION) Results Build log was saved at file://E:\Build\obj\JavaScriptCore\Release\BuildLog.htm JavaScriptCore - 1 error(s), 0 warning(s) WebCoreGenerated: Output Window Performing Makefile project actions Project : error PRJ0002 : Error result 1 returned from 'C:\WINDOWS\system32\cmd.exe'. Results Build log was saved at file://E:\Build\obj\WebCoreGenerated\Release\BuildLog.htm WebCoreGenerated - 1 error(s), 0 warning(s) and so on. The WebCore BuildLog.htm showed a lot of errors (918). Please let me know if I'm missing any thing. Thanks, Seby. On Tue, May 5, 2009 at 11:59 AM, Adam Roben aro...@apple.com wrote: On May 5, 2009, at 11:13 AM, Seby wrote: Any good news? Yes: http://trac.webkit.org/changeset/43239 Sorry for the delay. Let us know if you have any more trouble! -Adam . Are you using VC++ Express? If so, you might be running into this bug: https://bugs.webkit.org/show_bug.cgi?id=25308 I'll try to land a fix for that bug today. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Some questions about squirrelfish
Hi, - Is there any squirrelfish porting document? - How is calling the code generated by the function privatecompileCTIMachineTrampoline? Best regards. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Problem with building WebKit
It looks like Cygwin's link.exe is getting invoked instead of VC++ Express's link.exe. I suspect you have an issue with your PATH. You could try adding the directory that contains VC++ Express's link.exe to your PATH. -Adam On May 6, 2009, at 5:33 AM, Seby wrote: Hello Adam, I tried to build WebKit using the latest version and I see that the JavaScriptCoreGenerated without errors other than the xcopy error: Output Window Performing Makefile project actions xcopy /y/d/e/i ..\..\..\WebKitLibraries\win\tools E:\cygwin\home \Seby\WebKit\WebKitLibraries\win\tools Cannot perform a cyclic copy 0 File(s) copied touch E:\Build\buildfailed - - - - - - logs omitted - - - - - - Results Build log was saved at file://E:\Build\obj\JavaScriptCoreGenerated\Release\BuildLog.htm JavaScriptCoreGenerated - 0 error(s), 0 warning(s) And the second one (record-memory-win) failed w/ the link usage error as shown below: Output Window Compiling... main.cpp Linking... link: extra operand `/ERRORREPORT:QUEUE' Try `link --help' for more information. Project : error PRJ0002 : Error result 1 returned from 'E:\cygwin\bin \link.exe'. Results Build log was saved at file://E:\Build\obj\record-memory-win\Release\BuildLog.htm record-memory-win - 1 error(s), 0 warning(s) The thrid one (WTF) was successful showing the below Result: Results Build log was saved at file://E:\Build\obj\WTF\Release\BuildLog.htm WTF - 0 error(s), 0 warning(s) And again the link error on JavaScriptCore Performing Pre-Link Event... Linking... link: missing operand after `ÿþ/' Try `link --help' for more information. Project : error PRJ0002 : Error result 1 returned from 'E:\cygwin\bin \link.exe'. Project : warning PRJ0018 : The following environment variables were not found: $(PRODUCTION) Results Build log was saved at file://E:\Build\obj\JavaScriptCore\Release\BuildLog.htm JavaScriptCore - 1 error(s), 0 warning(s) WebCoreGenerated: Output Window Performing Makefile project actions Project : error PRJ0002 : Error result 1 returned from 'C:\WINDOWS \system32\cmd.exe'. Results Build log was saved at file://E:\Build\obj\WebCoreGenerated\Release\BuildLog.htm WebCoreGenerated - 1 error(s), 0 warning(s) and so on. The WebCore BuildLog.htm showed a lot of errors (918). Please let me know if I'm missing any thing. Thanks, Seby. On Tue, May 5, 2009 at 11:59 AM, Adam Roben aro...@apple.com wrote: On May 5, 2009, at 11:13 AM, Seby wrote: Any good news? Yes: http://trac.webkit.org/changeset/43239 Sorry for the delay. Let us know if you have any more trouble! -Adam . Are you using VC++ Express? If so, you might be running into this bug: https://bugs.webkit.org/show_bug.cgi?id=25308 I'll try to land a fix for that bug today. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
The goal of Origyn Web Browser Abstraction Layer (OWBAL) is to clarify what is platform dependant and what is not. In BAL directory you find some modules which split sources per family of feature: Database: all files needed for HTML5 Database and Storage. Events: all events definitions (input events) Filesystem: methods to access the filesystem Geolocation: methods to implement the html5 geolocation ImageDecoder: Interface of ImageDecoder and all implementation (GIF, JPEG, PNG, BMP, ICO) Media: Implementation of backend for HTML5 video/audio tag Network: Implementation of network resource Types: Base Type used by WebCore Facilities: misceleanous facilities implementation Fonts: Font engine implementation Graphics: Graphic primitive implementation (drawline, ...) Internationalization: I18N implementation Memory: memory management implementation SVG: SVG (graphic part, the parser is in WebCore) implementation Timer: timer implementation Widgets: widget implementation Each Module, when needed, splits WebCore and WTF source for the compilation. All files in BAL have the prefix BC for BAL Concretization and for the suffix the implementation name ( SDL, Gtk, Qt... ). This is done to avoid confusion between files in the BAL and WebCore. For example if you have a file ScrollView.cpp in WebCore, in BAL for SDL implementation it will be : BCScrollViewSDL.cpp This way any filename self documents its target implementation. We have a 2 others directories used for the BALification process: * Base: where stand definition of type and all configuration ( Platform.h, ... ). This makes a single place of information. *cmake: all definitions needed by cmake (our build mechanism) such as library check, header include, definitions by option. you can find this description here : http://www.sand- labs.org/owb/wiki/OwbalDescription Mario Le Tuesday 05 May 2009 17:19:33 Maciej Stachowiak, vous avez écrit : On May 4, 2009, at 5:21 AM, Mario Bensi wrote: We pursued the same goal for a couple of years. Since our porting targets are various middleware CE platforms, we had to identify and adapt WebKit needs at a better grained level than platform. In order to do this we collected all dependencies in a Browser Abstraction Layer (BAL directory). The configuration is handled by a Base directory (definition of types, platform specifications) and we use CMake to define platform specificities (and it's a great cross- platform tool). Sure the BAL model has still improvements ahead of it, but it has the merit of existing, being widely tester on a quite wide range of targets, configurations and libraries. My understanding is that BAL injects a platform abstration layer under the platform abstraction layer that is the WebCore/platform directory. Also, I gather that BAL tries to do more things via runtime indirection and subclasses with virtual methods instead of WebCore's compile-time approach. To me, those aspects sound like they may not be good fits for our goals. But I would be glad to hear more details about BAL, and how it would compare to my proposal. Regards, Maciej Regards Mario Le Friday 01 May 2009 01:12:54 Maciej Stachowiak, vous avez écrit : I think our set of porting macros has become somewhat confused. Originally, our idea was that a port represents primarily adaptation to a particular platform. However, over time it has become clear that most of what is decided by a port is not platform adaptation, but rather policy decisions. For example, ports decide to have different features enabled, or to use different sets of system functionality on the same underlying OS. In addition, I think the catchall top-level PLATFORM create confusion, because it is not totally clear if they are policy decisions, platform adaptation decisions, or what. Third, it seems wrong that the policy choices of every port are represented as a bunch of ifdef tomfoolery inside a single Platform.h file. And fourth, many ports often run on the same OS, but with a different set of choices - for example on Mac OS X it is possible to build the Mac, Chromium, Gtk, Qt and Wx ports (at least). Therefore, I propose that we change as follows: 1) Strictly separate platform adaptation (mandatory to run on a given OS, compiler, or CPU at all) from policy choices (what features to enable, what optional libraries to use). 2) Phase out PLATFORM macros completely - each use should be converted to a policy choice, or a platform adaptation decision. 3) Instead of ports being defined by a top-level PLATFORM macro, I propose that each port should have its own header file to define policy decisions. For example, I'd propose that the system Mac OS X WebKit should use PortCocoa.h, and the WebKit used by Safari for Windows should use PortWinCG.h. There may also be a PortIPhone.h. These port definition headers
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
On 5-May-09, at 10:49 AM, Darin Adler wrote: On May 4, 2009, at 7:45 PM, George Staikos wrote: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) How? Macros don’t have overloading with the same macro but different numbers of parameters. Hm I guess variable argument macros are not supported everywhere we need them. Oh well. On 5-May-09, at 11:16 AM, Maciej Stachowiak wrote: On May 4, 2009, at 7:45 PM, George Staikos wrote: I really like this and it goes in the direction that I was hoping for as well. Hopefully we can get the WINCE port merged upstream before we make this change. :-) Some comments I have: 1) In some cases some things apply to more than one OS so we have: #if OS(x) || OS(y) || OS(z) ... I think we should use: #if OS(x,y,z) I think using the || operator is more clear, except perhaps in cases where there is a well-defined OS family, such as the Unix- like family of operating systems, or the Windows family. In that case, the OS family should get is own macro. Well my idea probably won't work anyway given that not enough compilers we need to support can handle it. 1b) WINCE actually includes plenty of WIN but in some cases does things differently. How to make this distinction without lots of and ||? Perhaps we need another basic OS macro besides WINCE and WIN, which would refer to only full/desktop versions of Windows. Or maybe WIN should mean desktop Windows, and some new macro could represent the facilities that are common to Windows and Windows CE. Then it's just a matter of using the right ifdefs in the right place. So something like this (for example) in Platform.h? #if OS(WINMOBILE) #define WTF_OS_WINCE 1 #endif #if OS(WINCE) || OS(WINDESKTOP) #define WTF_OS_WIN 1 #endif Then OS(WIN) would mean any Windows flavour, and OS(WINCE) would mean any flavour of Windows CE. Again, fully support these changes and perhaps some more too. Just give us a bit of time to find the right way to merge the WINCE stuff in first please! I wouldn't expect us to start changing things next week, but since generally I've heard support for these changes, I would expect in a month or two at most we'll likely start on deploying them. Most likely we will come up with a system that allows gradual migration. At some point, we'll likely require new code to use new-style macros only and not the old PLATFORM stuff. Great! Well I'm ready to start packaging things up. Will try to get the first (and most relevant) parts ready this week. -- George Staikos Torch Mobile Inc. http://www.torchmobile.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] setting a size limit for Application Cache
Hi, I was recently looking at https://bugs.webkit.org/show_bug.cgi?id=22700 I have a small patch that attempts to fix this issue by 1. allowing the ChromeClient implementers to decide what the size limit should be, 2. evicting caches (in LRU order) from the database when the size limit is reached and a new cache needs to be saved. After an initial discussion with Alexey Proskuryakov on IRC, we agreed to ask webkit-dev for advice on this matter: is LRU eviction the correct thing to do? It seems clear that the intended usage of Application Cache is to act as a repository for Web applications that can be used offline. However, when the disk space allowed for this is completely used up, would it be ok to make room for new apps by automatically evicting existing ones? The advantage of this is that it allows this feature to function without any UI at all. The drawback is that some apps would suddenly stop working offline. The alternative is to simply throw an error when the size limit is reached and expect the UA to provide some UI that allows users to free space by uninstalling existing apps. However, having another setting for this may turn out to be inconvenient (it's hard to discover and increases the burden on users who already have to deal with cookies, normal HTTP cache, databases, geolocation, etc). Many thanks, Andrei ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MessagePorts and garbage collection
Hi all,
I'm fixing some race conditions in the MessagePort code, and I want to make
sure I understand how garbage collection works for things like MessagePorts
that are access across multiple threads.
Some quick background: HTML5 MessagePorts are essentially two ends of a
message channel - messages posted to one MessagePort are raised as events on
the corresponding paired (entangled) MessagePort. They are used for
window-worker messaging, so each MessagePort may be run by a different
thread.
I'm simplifying the situation a bit, but in general as long as there is a
reference to one of the MessagePorts, both port objects should be treated as
reachable for the purposes of garbage collection. There is code in
bindings/js/JSMessagePortCustom.cpp to handle this, by invoking mark() on
the entangled port.
void JSMessagePort::mark()
{
DOMObject::mark();
...
if (MessagePortProxy* entangledPort = m_impl-entangledPort()) {
DOMObject* wrapper =
getCachedDOMObjectWrapper(*Heap::heap(this)-globalData(), entangledPort);
if (wrapper !wrapper-marked())
*wrapper-mark();*
}
...
}
There's one wrinkle, however - it's possible (via MessagePort::clone()) to
change the linkage between the two MessagePorts ; essentially one object is
swapped out for the other which requires updating the linkage on both ends.
If this were to happen in the middle of a GC operation, that would be bad.
It looks like the JSC collection code relies on JSLock to lock the heap -
I'm guessing that I'll need to explicitly grab the JSLock whenever I'm
manipulating the linkage between the two ports, is that correct? Or is there
a different/better way to handle situations like this?
-atw
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit Javascript Popups
Hi, I'm a developer for Uzbl (http://www.uzbl.org) and we've got a problem with opening new links via javascript's window.open(). We don't know how to get the URI being requested, and so no new window is opened. How can we get the URI? Thanks -- Michael Walker (http://www.barrucadu.co.uk) Rembrandt is not to be compared in the painting of character with our extraordinarily gifted English artist, Mr. Rippingille. -- John Hunt, British editor, scholar and art critic Cerf/Navasky, The Experts Speak ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
The way I see it, there's 2 uses for AppCache in the mobile space: Simply speeding things up (i.e. just a cache) and web applications you'd like to use offline. For the first use case, automatic eviction (presumably via LRU) is quite acceptable. For the second use case, I think you need some way to pin the app in the cache. Anything that's pinned would not be subject to LRU. If the user wanted to pin an app, but the memory was full of other pinned apps, you could then present the user with an uninstall dialog. I agree that the less UI the better, but I know I'd be mad if I gmail offline stopped working simply because I hadn't visited the site in a while. J On Wed, May 6, 2009 at 11:37 AM, Jeremy Orlow jor...@google.com wrote: The way I see it, there's 2 uses for AppCache in the mobile space: Simply speeding things up (i.e. just a cache) and web applications you'd like to use offline. For the first use case, automatic eviction (presumably via LRU) is quite acceptable. For the second use case, I think you need some way to pin the app in the cache. Anything that's pinned would not be subject to LRU. If the user wanted to pin an app, but the memory was full of other pinned apps, you could then present the user with an uninstall dialog. I agree that the less UI the better, but I know I'd be mad if I gmail offline stopped working simply because I hadn't visited the site in a while. J On Wed, May 6, 2009 at 9:23 AM, Andrei Popescu andr...@google.com wrote: Hi, I was recently looking at https://bugs.webkit.org/show_bug.cgi?id=22700 I have a small patch that attempts to fix this issue by 1. allowing the ChromeClient implementers to decide what the size limit should be, 2. evicting caches (in LRU order) from the database when the size limit is reached and a new cache needs to be saved. After an initial discussion with Alexey Proskuryakov on IRC, we agreed to ask webkit-dev for advice on this matter: is LRU eviction the correct thing to do? It seems clear that the intended usage of Application Cache is to act as a repository for Web applications that can be used offline. However, when the disk space allowed for this is completely used up, would it be ok to make room for new apps by automatically evicting existing ones? The advantage of this is that it allows this feature to function without any UI at all. The drawback is that some apps would suddenly stop working offline. The alternative is to simply throw an error when the size limit is reached and expect the UA to provide some UI that allows users to free space by uninstalling existing apps. However, having another setting for this may turn out to be inconvenient (it's hard to discover and increases the burden on users who already have to deal with cookies, normal HTTP cache, databases, geolocation, etc). Many thanks, Andrei ___ 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] setting a size limit for Application Cache
The chrome team had an interesting thread on this topic not long ago. Unfortunately it wasn't on the public chromium-dev mailing list, so I can't provide a link to it here :( summary (according to me at least:) The gist of it was that providing appcaching for general use w/o any special privileges is a good thing, but not all usages of this feature are qualitatively the same thing. In some cases it's purely about performance enhancement or reduced network utilization (traditional caching goals). In other cases it's about providing additional guarantees around application availability. Its fair to evict data cached for the former cases as needed, but not ok to evict data cached for the latter cases. There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. In the latter case (gauranteed app availability), there is more involved than the appcache... there are also databases, localstorage values to which the gaurantee extends to. What's missing is a way for applications to declare themselves as such and to establish privileges to keep data around forever. Given that, the system could relate persistent resource with applications, and based on their privileges, evict or not when space becomes an issue. A handwavvy syntax for declaring an application... html application='someurl'... the url uniquely identifies the app, the resource loaded from that url contains a user friendly description and set of desired privileges... all pages that refer to that application url are considered part of that app... all resource created on behalf of that app are tracked by the system as such. Food for thought. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit Javascript Popups
Am Wed, 6 May 2009 20:21:14 +0100 schrieb Michael S. Walker m...@barrucadu.co.uk: Hi, I'm a developer for Uzbl (http://www.uzbl.org) and we've got a problem with opening new links via javascript's window.open(). We don't know how to get the URI being requested, and so no new window is opened. How can we get the URI? Thanks Hey Michael, have a look at the create-web-view signal in WebKitWebView, ie. /WebKit/gtk/webkit/webkitwebview.cpp Yours, Christian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
Good point. Tying the apps together is pretty important. What good is it for the program to still be in AppCache if it's data (in databases or localStorage) was deleted by some other LRU policy? I'm not sure that yet another manifest is needed though. For databases and localStorage, access is controlled via the origin. It seems to me that the minimum granularity for what gets pinned is thus the domain. Yes, there can be multiple web applications per domain, but there's really no way for WebKit to know which localStorage entries or which databases are tied to each application. Thus, eviction is an all or nothing thing for the origin. This is not such a horrible thing though; authors can always create sub-domains for each web application. So, in summary: I'm proposing that there be a UI to pin (or install, or save, or whatever you want to call it) an origin + have a dialog for seeing all the origins that are pined (for uninstall purposes). All non-pinned AppCache data would be removed in a LRU fashion. J On Wed, May 6, 2009 at 12:09 PM, Michael Nordman micha...@google.comwrote: The chrome team had an interesting thread on this topic not long ago. Unfortunately it wasn't on the public chromium-dev mailing list, so I can't provide a link to it here :( summary (according to me at least:) The gist of it was that providing appcaching for general use w/o any special privileges is a good thing, but not all usages of this feature are qualitatively the same thing. In some cases it's purely about performance enhancement or reduced network utilization (traditional caching goals). In other cases it's about providing additional guarantees around application availability. Its fair to evict data cached for the former cases as needed, but not ok to evict data cached for the latter cases. There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. In the latter case (gauranteed app availability), there is more involved than the appcache... there are also databases, localstorage values to which the gaurantee extends to. What's missing is a way for applications to declare themselves as such and to establish privileges to keep data around forever. Given that, the system could relate persistent resource with applications, and based on their privileges, evict or not when space becomes an issue. A handwavvy syntax for declaring an application... html application='someurl'... the url uniquely identifies the app, the resource loaded from that url contains a user friendly description and set of desired privileges... all pages that refer to that application url are considered part of that app... all resource created on behalf of that app are tracked by the system as such. Food for thought. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
On Wed, May 6, 2009 at 12:45 PM, Jeremy Orlow jor...@google.com wrote: Good point. Tying the apps together is pretty important. What good is it for the program to still be in AppCache if it's data (in databases or localStorage) was deleted by some other LRU policy? I'm not sure that yet another manifest is needed though. For databases and localStorage, access is controlled via the origin. It seems to me that the minimum granularity for what gets pinned is thus the domain. Assuming app == domain has proven problematic. Not only are there multiple apps per domain, there are apps that span multiple domains. Yes, there can be multiple web applications per domain, but there's really no way for WebKit to know which localStorage entries or which databases are tied to each application. Thus, eviction is an all or nothing thing for the origin. This is not such a horrible thing though; authors can always create sub-domains for each web application. sub-domains for each web application has proven to be easier said than done So, in summary: I'm proposing that there be a UI to pin (or install, or save, or whatever you want to call it) an origin + have a dialog for seeing all the origins that are pined (for uninstall purposes). All non-pinned AppCache data would be removed in a LRU fashion. Some thing the system needs is a 'trigger' to bring up such a UI. The presence of a html application='someurl' attribute, in which the descriptor file expresses it desire for the 'persistance' privilege, could provide such a trigger. On Wed, May 6, 2009 at 12:09 PM, Michael Nordman micha...@google.com wrote: The chrome team had an interesting thread on this topic not long ago. Unfortunately it wasn't on the public chromium-dev mailing list, so I can't provide a link to it here :( summary (according to me at least:) The gist of it was that providing appcaching for general use w/o any special privileges is a good thing, but not all usages of this feature are qualitatively the same thing. In some cases it's purely about performance enhancement or reduced network utilization (traditional caching goals). In other cases it's about providing additional guarantees around application availability. Its fair to evict data cached for the former cases as needed, but not ok to evict data cached for the latter cases. There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. In the latter case (gauranteed app availability), there is more involved than the appcache... there are also databases, localstorage values to which the gaurantee extends to. What's missing is a way for applications to declare themselves as such and to establish privileges to keep data around forever. Given that, the system could relate persistent resource with applications, and based on their privileges, evict or not when space becomes an issue. A handwavvy syntax for declaring an application... html application='someurl'... the url uniquely identifies the app, the resource loaded from that url contains a user friendly description and set of desired privileges... all pages that refer to that application url are considered part of that app... all resource created on behalf of that app are tracked by the system as such. Food for thought. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
On Wed, May 6, 2009 at 1:12 PM, Michael Nordman micha...@google.com wrote: On Wed, May 6, 2009 at 12:45 PM, Jeremy Orlow jor...@google.com wrote: Good point. Tying the apps together is pretty important. What good is it for the program to still be in AppCache if it's data (in databases or localStorage) was deleted by some other LRU policy? I'm not sure that yet another manifest is needed though. For databases and localStorage, access is controlled via the origin. It seems to me that the minimum granularity for what gets pinned is thus the domain. Assuming app == domain has proven problematic. Not only are there multiple apps per domain, there are apps that span multiple domains. Yes, there can be multiple web applications per domain, but there's really no way for WebKit to know which localStorage entries or which databases are tied to each application. Thus, eviction is an all or nothing thing for the origin. This is not such a horrible thing though; authors can always create sub-domains for each web application. sub-domains for each web application has proven to be easier said than done Don't look at me. I'm not the one who made the standard. Unfortunately the standard makes it virtually impossible for offline apps to span domains and for you to cherry pick between multiple apps on one domain. We might as well embrace this fact and thus avoid creating yet another manifest. (Assuming others agree with our assumption that we do need some way to pin applications.) So, in summary: I'm proposing that there be a UI to pin (or install, or save, or whatever you want to call it) an origin + have a dialog for seeing all the origins that are pined (for uninstall purposes). All non-pinned AppCache data would be removed in a LRU fashion. Some thing the system needs is a 'trigger' to bring up such a UI. The presence of a html application='someurl' attribute, in which the descriptor file expresses it desire for the 'persistance' privilege, could provide such a trigger. I think the presence of an AppCache manifest is enough. An application can't work offline without it. On Wed, May 6, 2009 at 12:09 PM, Michael Nordman micha...@google.com wrote: The chrome team had an interesting thread on this topic not long ago. Unfortunately it wasn't on the public chromium-dev mailing list, so I can't provide a link to it here :( summary (according to me at least:) The gist of it was that providing appcaching for general use w/o any special privileges is a good thing, but not all usages of this feature are qualitatively the same thing. In some cases it's purely about performance enhancement or reduced network utilization (traditional caching goals). In other cases it's about providing additional guarantees around application availability. Its fair to evict data cached for the former cases as needed, but not ok to evict data cached for the latter cases. There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. In the latter case (gauranteed app availability), there is more involved than the appcache... there are also databases, localstorage values to which the gaurantee extends to. What's missing is a way for applications to declare themselves as such and to establish privileges to keep data around forever. Given that, the system could relate persistent resource with applications, and based on their privileges, evict or not when space becomes an issue. A handwavvy syntax for declaring an application... html application='someurl'... the url uniquely identifies the app, the resource loaded from that url contains a user friendly description and set of desired privileges... all pages that refer to that application url are considered part of that app... all resource created on behalf of that app are tracked by the system as such. Food for thought. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MessagePorts and garbage collection
06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] AppCache resource loading in a multi-process world
Hi all, Please refer to https://bugs.webkit.org/show_bug.cgi?id=25436. Alexey and I have been trading messages in that issue. He suggested that I bring this up aspects of that issue on the larger list. I think that the best way forward is to discuss general multi-process loader architecture on the mailing list, with appcache design being a natural part of it. The issue is how to accommodate loading out of an appcache in a multi-process browser. I've been working towards a solution where the main process is the only process with direct access to the appcache data on disk. Please see the bug for details. Thnx Michael ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
06.05.2009, в 23:09, Michael Nordman написал(а): There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. The first use case (just speeding things up) sounds like something that should be handled by a normal HTTP cache, as defined in RFC 2616. Is it inadequate? If it is, maybe it should be improved instead of making an additional entirely different caching mechanism? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MessagePorts and garbage collection
OK, that's good to know (it only supports document contexts) - clearly some work has been done to prepare for multi-thread usage (for example, the core data structure is a thread-safe MessageQueue). I'm quite happy to drive this design (in fact, I'm in the middle of this now) but I would like to make sure I understand in general what the correct approach is for managing GC-able objects that are accessed cross-thread - I haven't been able to find any documentation (outside of the code itself). Is the right approach to use JSLock when manipulating cross-thread linkage? I'll write up a quick document to describe the approach I'm taking, but I'd like to understand your concerns about deadlocks. So long as we have only a single shared per-channel mutex, and we never grab any other locks (like JSLock) after grabbing that mutex, we should be OK. Are there other locks that may be grabbed behind the scenes that I should be aware of? -atw 2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 23:09, Michael Nordman написал(а): There is no means for the system to distinguish between these two cases. There is no API to indicate which use is which. The first use case (just speeding things up) sounds like something that should be handled by a normal HTTP cache, as defined in RFC 2616. Is it inadequate? If it is, maybe it should be improved instead of making an additional entirely different caching mechanism? The advantage AppCaches have vs normal caches is that they're explicitly versioned by the developer. If I have a big, complex application that has many files, I can specify it all in the AppCache manifest to make it go faster (not check each file for a newer version)--even if I'm not going to make it work offline. How many developers will want to use it this way? Hard to say, but probably not too many. So maybe there should be no implicit use of AppCache...at least at first? Or am I missing some non-offline use-cases here? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] setting a size limit for Application Cache
On May 6, 2009, at 11:40 AM, Jeremy Orlow wrote: The way I see it, there's 2 uses for AppCache in the mobile space: Simply speeding things up (i.e. just a cache) and web applications you'd like to use offline. For the first use case, automatic eviction (presumably via LRU) is quite acceptable. For the second use case, I think you need some way to pin the app in the cache. Anything that's pinned would not be subject to LRU. If the user wanted to pin an app, but the memory was full of other pinned apps, you could then present the user with an uninstall dialog. I agree that the less UI the better, but I know I'd be mad if I gmail offline stopped working simply because I hadn't visited the site in a while. I think it would be reasonable to assume that all uses of AppCache are for use case #2, declaring an application that can potentially be used offline. At least, I can't think of anyone eager to use AppCache solely for performance. If it becomes such a widely used feature that manual choice to remove an AppCache is not good enough for management, then we could add a way for the app to draw a distinction. I think adding a way to have some offline resources declared pinned and others cleaned up in an LRU fashion in the implementation would be ok, as it would allow making this choice through the UI, which seems reasonable. - Maciej J On Wed, May 6, 2009 at 11:37 AM, Jeremy Orlow jor...@google.com wrote: The way I see it, there's 2 uses for AppCache in the mobile space: Simply speeding things up (i.e. just a cache) and web applications you'd like to use offline. For the first use case, automatic eviction (presumably via LRU) is quite acceptable. For the second use case, I think you need some way to pin the app in the cache. Anything that's pinned would not be subject to LRU. If the user wanted to pin an app, but the memory was full of other pinned apps, you could then present the user with an uninstall dialog. I agree that the less UI the better, but I know I'd be mad if I gmail offline stopped working simply because I hadn't visited the site in a while. J On Wed, May 6, 2009 at 9:23 AM, Andrei Popescu andr...@google.com wrote: Hi, I was recently looking at https://bugs.webkit.org/show_bug.cgi?id=22700 I have a small patch that attempts to fix this issue by 1. allowing the ChromeClient implementers to decide what the size limit should be, 2. evicting caches (in LRU order) from the database when the size limit is reached and a new cache needs to be saved. After an initial discussion with Alexey Proskuryakov on IRC, we agreed to ask webkit-dev for advice on this matter: is LRU eviction the correct thing to do? It seems clear that the intended usage of Application Cache is to act as a repository for Web applications that can be used offline. However, when the disk space allowed for this is completely used up, would it be ok to make room for new apps by automatically evicting existing ones? The advantage of this is that it allows this feature to function without any UI at all. The drawback is that some apps would suddenly stop working offline. The alternative is to simply throw an error when the size limit is reached and expect the UA to provide some UI that allows users to free space by uninstalling existing apps. However, having another setting for this may turn out to be inconvenient (it's hard to discover and increases the burden on users who already have to deal with cookies, normal HTTP cache, databases, geolocation, etc). Many thanks, Andrei ___ 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] MessagePorts and garbage collection
On May 6, 2009, at 1:53 PM, Drew Wilson wrote: OK, that's good to know (it only supports document contexts) - clearly some work has been done to prepare for multi-thread usage (for example, the core data structure is a thread-safe MessageQueue). I'm quite happy to drive this design (in fact, I'm in the middle of this now) but I would like to make sure I understand in general what the correct approach is for managing GC-able objects that are accessed cross-thread - I haven't been able to find any documentation (outside of the code itself). Is the right approach to use JSLock when manipulating cross-thread linkage? I'll write up a quick document to describe the approach I'm taking, but I'd like to understand your concerns about deadlocks. So long as we have only a single shared per-channel mutex, and we never grab any other locks (like JSLock) after grabbing that mutex, we should be OK. Are there other locks that may be grabbed behind the scenes that I should be aware of? JSLock is not the right approach. Workers have their own completely separate GC heap. JSLock only locks the current context group's heap. It will not prevent collection in other heaps. I don't know exactly what the right approach is. Ultimately it's a distributed GC problem, both for our split-heap multithreading and for an approach that used processes for workers. And distributed GC is hard. However, Worker itself has a similar issue, since it can be kept alive either from the inside or the outside reference. You could look at how that problem was solved. - Maciej -atw 2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - 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] Problem with building WebKit
On May 6, 2009, at 7:15 PM, Seby wrote: I've already tried to build the same after removing the WebKit Build directory and updating to latest source from svn. Do you meant to try reinstalling the MS VC++ Express and PlatformSDK? No, I meant to remove the WebKitBuild directory, like you said you did. Are there any failures in the WebCoreGenerated project? That's the project that generates SVGNames.h. -Adam On Wed, May 6, 2009 at 2:46 PM, Adam Roben aro...@apple.com wrote: On May 6, 2009, at 2:41 PM, Seby wrote: Yes, That is the issue. It now fails at WebCore and here is the errors: Output Window - - - - - - - - SVGResourceFilterCg.cpp SVGResourceMasker.cpp e:\cygwin\home\seby\webkit\webcore\svg\SVGElement.h(29) : fatal error C1083: Cannot open include file: 'SVGNames.h': No such file or directory SVGResourceMarker.cpp SVGResourceFilter.cpp SVGResourceClipper.cpp SVGResource.cpp e:\cygwin\home\Seby\WebKit\WebCore\svg\SVGElement.h(29) : fatal error C1083: Cannot open include file: 'SVGNames.h': No such file or directory SVGPaintServerSolid.cpp SVGPaintServerRadialGradient.cpp SVGPaintServerPattern.cpp e:\cygwin\home\seby\webkit\webcore\svg\SVGElement.h(29) : fatal error C1083: Cannot open include file: 'SVGNames.h': No such file or directory SVGPaintServerLinearGradient.cpp - - - - - - - - I can see these files in this directory using Windows Explorer or MyComputer. Do you think it is fails due to the upper/lower case issue of my home directory? I think you're seeing SVGNames.in, which is the filed used to generate SVGNames.h. Do you see any earlier errors in the WebCoreGenerated project about failing to generate this file? You might want to try doing a clean build now that you've gotten these other errors fixed. -Adam On Wed, May 6, 2009 at 11:21 AM, Adam Roben aro...@apple.com wrote: It looks like Cygwin's link.exe is getting invoked instead of VC++ Express's link.exe. I suspect you have an issue with your PATH. You could try adding the directory that contains VC++ Express's link.exe to your PATH. -Adam On May 6, 2009, at 5:33 AM, Seby wrote: Hello Adam, I tried to build WebKit using the latest version and I see that the JavaScriptCoreGenerated without errors other than the xcopy error: Output Window Performing Makefile project actions xcopy /y/d/e/i ..\..\..\WebKitLibraries\win\tools E:\cygwin \home\Seby\WebKit\WebKitLibraries\win\tools Cannot perform a cyclic copy 0 File(s) copied touch E:\Build\buildfailed - - - - - - logs omitted - - - - - - Results Build log was saved at file://E:\Build\obj\JavaScriptCoreGenerated\Release\BuildLog.htm JavaScriptCoreGenerated - 0 error(s), 0 warning(s) And the second one (record-memory-win) failed w/ the link usage error as shown below: Output Window Compiling... main.cpp Linking... link: extra operand `/ERRORREPORT:QUEUE' Try `link --help' for more information. Project : error PRJ0002 : Error result 1 returned from 'E:\cygwin \bin\link.exe'. Results Build log was saved at file://E:\Build\obj\record-memory-win\Release\BuildLog.htm record-memory-win - 1 error(s), 0 warning(s) The thrid one (WTF) was successful showing the below Result: Results Build log was saved at file://E:\Build\obj\WTF\Release \BuildLog.htm WTF - 0 error(s), 0 warning(s) And again the link error on JavaScriptCore Performing Pre-Link Event... Linking... link: missing operand after `ÿþ/' Try `link --help' for more information. Project : error PRJ0002 : Error result 1 returned from 'E:\cygwin \bin\link.exe'. Project : warning PRJ0018 : The following environment variables were not found: $(PRODUCTION) Results Build log was saved at file://E:\Build\obj\JavaScriptCore\Release\BuildLog.htm JavaScriptCore - 1 error(s), 0 warning(s) WebCoreGenerated: Output Window Performing Makefile project actions Project : error PRJ0002 : Error result 1 returned from 'C:\WINDOWS \system32\cmd.exe'. Results Build log was saved at file://E:\Build\obj\WebCoreGenerated\Release\BuildLog.htm WebCoreGenerated - 1 error(s), 0 warning(s) and so on. The WebCore BuildLog.htm showed a lot of errors (918). Please let me know if I'm missing any thing. Thanks, Seby. On Tue, May 5, 2009 at 11:59 AM, Adam Roben aro...@apple.com wrote: On May 5, 2009, at 11:13 AM, Seby wrote: Any good news? Yes: http://trac.webkit.org/changeset/43239 Sorry for the delay. Let us know if you have any more trouble! -Adam . Are you using VC++ Express? If so, you might be running into this bug: https://bugs.webkit.org/show_bug.cgi?id=25308 I'll try to land a fix for that bug today. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MessagePorts and garbage collection
Thanks, this puts me on the right track. I've had a bunch of discussions with the Chrome folks on how we'd track MessagePort reachability in Chrome, but I'd hoped that the problem might be simpler in WebKit since we had direct access to the data structures cross-thread. The existence of separate GC heaps means it's not particularly simpler after all. -atw 2009/5/6 Maciej Stachowiak m...@apple.com On May 6, 2009, at 1:53 PM, Drew Wilson wrote: OK, that's good to know (it only supports document contexts) - clearly some work has been done to prepare for multi-thread usage (for example, the core data structure is a thread-safe MessageQueue). I'm quite happy to drive this design (in fact, I'm in the middle of this now) but I would like to make sure I understand in general what the correct approach is for managing GC-able objects that are accessed cross-thread - I haven't been able to find any documentation (outside of the code itself). Is the right approach to use JSLock when manipulating cross-thread linkage? I'll write up a quick document to describe the approach I'm taking, but I'd like to understand your concerns about deadlocks. So long as we have only a single shared per-channel mutex, and we never grab any other locks (like JSLock) after grabbing that mutex, we should be OK. Are there other locks that may be grabbed behind the scenes that I should be aware of? JSLock is not the right approach. Workers have their own completely separate GC heap. JSLock only locks the current context group's heap. It will not prevent collection in other heaps. I don't know exactly what the right approach is. Ultimately it's a distributed GC problem, both for our split-heap multithreading and for an approach that used processes for workers. And distributed GC is hard. However, Worker itself has a similar issue, since it can be kept alive either from the inside or the outside reference. You could look at how that problem was solved. - Maciej -atw 2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - 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] MessagePorts and garbage collection
Following up. I think I have my head around how Worker GC is happening (I may start another thread about that, as it looks like there's some cases where the thread won't be shut down, but the general design is sound). MessagePort GC is a little trickier, because we need to detect when both sides have no external references, based on this part of the HTML5 spec: [...] a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained. Of course, if this was to occur on both sides of the channel, then both ports would be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other. From looking at the code in bindings/js, it looks like I've got two tools to manage object reachability: 1) I can tell when my object is reachable (during a GC) because mark() will be invoked on it. 2) I can force my object to stay active (as long as the owning context is active) by making it an ActiveDOMObject and returning true from hasPendingActivity() (which seems like it does nothing but invoke mark() on the object). So, #2 lets me keep an object alive, but to implement the spec, I need to be able to detect when my object has no more references, without actually having it get garbage collected. If I can do that, then I can build my own distributed state mechanism to allow me to determine when it's safe to GC the objects. I'm looking through the JSC::Collector code, and I didn't see anything that did exactly what I want, but there are probably some things that we could do with protect() to enable this. Has anyone else had to do anything like what I describe above? It's not exactly even a multi-thread issue, as it seems like this problem would occur even with just a single thread. -atw 2009/5/6 Drew Wilson atwil...@google.com Thanks, this puts me on the right track. I've had a bunch of discussions with the Chrome folks on how we'd track MessagePort reachability in Chrome, but I'd hoped that the problem might be simpler in WebKit since we had direct access to the data structures cross-thread. The existence of separate GC heaps means it's not particularly simpler after all. -atw 2009/5/6 Maciej Stachowiak m...@apple.com On May 6, 2009, at 1:53 PM, Drew Wilson wrote: OK, that's good to know (it only supports document contexts) - clearly some work has been done to prepare for multi-thread usage (for example, the core data structure is a thread-safe MessageQueue). I'm quite happy to drive this design (in fact, I'm in the middle of this now) but I would like to make sure I understand in general what the correct approach is for managing GC-able objects that are accessed cross-thread - I haven't been able to find any documentation (outside of the code itself). Is the right approach to use JSLock when manipulating cross-thread linkage? I'll write up a quick document to describe the approach I'm taking, but I'd like to understand your concerns about deadlocks. So long as we have only a single shared per-channel mutex, and we never grab any other locks (like JSLock) after grabbing that mutex, we should be OK. Are there other locks that may be grabbed behind the scenes that I should be aware of? JSLock is not the right approach. Workers have their own completely separate GC heap. JSLock only locks the current context group's heap. It will not prevent collection in other heaps. I don't know exactly what the right approach is. Ultimately it's a distributed GC problem, both for our split-heap multithreading and for an approach that used processes for workers. And distributed GC is hard. However, Worker itself has a similar issue, since it can be kept alive either from the inside or the outside reference. You could look at how that problem was solved. - Maciej -atw 2009/5/6 Alexey Proskuryakov a...@webkit.org 06.05.2009, в 21:38, Drew Wilson написал(а): It looks like the JSC collection code relies on JSLock to lock the heap - I'm guessing that I'll need to explicitly grab the JSLock whenever I'm manipulating the linkage between the two ports, is that correct? Or is there a different/better way to handle situations like this? The JavaScriptCore implementation of MessagePorts only supports document contexts (i.e., it only works on main thread). As mentioned earlier, the first thing needed to implement MessagePorts in workers is a design of how they can be passed around without breaking GC. It is likely that taking a lock whenever atomicity is desired will cause deadlocks. - 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
