Very cool investigation! I see WebKitClient::currentTime() in the upcoming WebKit API so I guess the idea is that client of WebKit would provide "the central clock". I agree "central clock" is a good idea. Currently in Webkit, it's provided by WTF. Embedders (like Safari) use WTF directly, for which WTF stuff is exposed by JavaScriptCore.exp.
Do we want to provide central clock from Chromium because we think the Chromium's implementation of currentTime is better? If so, wouldn't it be simpler to just replace the WTF one? ChromiumCurrentTime.cpp looks like a temporary hack... Dmitry On Tue, Oct 27, 2009 at 6:48 PM, Peter Kasting <[email protected]> wrote: > On Tue, Oct 27, 2009 at 4:40 PM, James Robinson <[email protected]>wrote: > >> So what's the problem? WTF::currentTime() is implemented twice, once in >> JavaScriptCore/wtf/CurrentTime.cpp and once in >> webkit/api/src/ChromiumCurrentTime.cpp. The latter simply defers to >> base::Time::Now().ToDoubleT(), the former uses a somewhat different >> algorithm to try to normalize what the system returns. ThreadTimers.cpp was >> linking against the JavaScriptCore/wtf/CurrentTime.cpp version and >> webkitclient_impl.cc was linking against the >> webkit/api/src/ChromiumCurrentTime.cpp version. >> > > Arrrgghhhhhh > > Is there a way we can compile-time detect similar symbol names like this > and throw fits (with a whitelist for any we know are OK)? Seems like this > is an issue for something with linking that maruel might have looked at long > ago. > > PKJ > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
