Summary: | [Gtk] Adding webkit_init to the API instead of calling it inside the class_init functions | ||
---|---|---|---|
Product: | WebKit | Reporter: | Alejandro G. Castro <alex> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | christian, gustavo, jmalonzo, mrobinson, xan.lopez |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | PC | ||
OS: | All | ||
Bug Depends on: | 35471 | ||
Bug Blocks: |
Description
Alejandro G. Castro
2009-10-06 02:10:47 PDT
(In reply to comment #0) > We have found some situations where doing the transparent initialization of the > class_init functions is not enough, for instance when a program starts creating > a KURL, the developers would have to call other function that calls the init > before creating the object. This is causing problems like the one in the bug > 28947, which could be in other parts of the library API. > Xan has pointed out in the bug 28947#3 that KURL is not a problem because it is not a public API, and the only problem is actually all the places in the library that we use that API, as always, he is right :). Apparently more consequences of this problem, race conditions in some situations that are causing tests to randomly fail, for instance: http://build.webkit.org/results/GTK%20Linux%2032-bit%20Debug/r49936%20(465)/storage/close-during-stress-test-stderr.txt http://build.webkit.org/results/GTK%20Linux%2032-bit%20Debug/r49936%20(465)/storage/test-authorizer-stderr.txt For the record, I am in favor of requiring that webkit_init be called, and we can, in addition to calling it where we currently do, to keep compatibility, check if it has already been called, and, if not, emit a warning saying this is deprecated. So this is just a problem for tests, isn't it? Or are there real use cases where an application runs into race conditions? The public objects initialize if needed as far as I'm aware. Is this still an issue? The GTK+ port of WebKit1 has been removed. |