RESOLVED FIXED 64841
Revert worker and WebKit2 runloops to use currentTime() for scheduling instead of the monotonic clock
https://bugs.webkit.org/show_bug.cgi?id=64841
Summary Revert worker and WebKit2 runloops to use currentTime() for scheduling instea...
James Robinson
Reported 2011-07-19 18:19:58 PDT
Revert worker and WebKit2 runloops to use currentTime() for scheduling instead of the monotonic clock
Attachments
Patch (8.75 KB, patch)
2011-07-19 18:25 PDT, James Robinson
no flags
add missing include (8.60 KB, patch)
2011-07-19 18:30 PDT, James Robinson
no flags
James Robinson
Comment 1 2011-07-19 18:25:01 PDT
WebKit Review Bot
Comment 2 2011-07-19 18:28:09 PDT
Comment on attachment 101417 [details] Patch Attachment 101417 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/9209064
James Robinson
Comment 3 2011-07-19 18:30:14 PDT
Created attachment 101418 [details] add missing include
James Robinson
Comment 4 2011-07-20 10:44:54 PDT
Comment on attachment 101418 [details] add missing include Thanks, Mark
WebKit Review Bot
Comment 5 2011-07-20 11:43:58 PDT
Comment on attachment 101418 [details] add missing include Clearing flags on attachment: 101418 Committed r91383: <http://trac.webkit.org/changeset/91383>
WebKit Review Bot
Comment 6 2011-07-20 11:44:04 PDT
All reviewed patches have been landed. Closing bug.
Jon
Comment 7 2011-07-20 13:03:12 PDT
Just wanted to add that I think this reversion fixed the issue I had been seeing lately on ToT where the Flash plugin didn't launch when issuing the Load Flash command through the ClickToFlash Safari plugin. I don't know if they're actually related, but it may give you an example to look at to make sure the behavior doesn't recur.
Balazs Kelemen
Comment 8 2011-07-20 16:05:32 PDT
Do we want to actually fix the bugs in favor of consequently using monotonicallyIncreasingTime where it is appropriate? Do you think it is a good idea to file a bug for that?
Ryosuke Niwa
Comment 9 2011-07-20 21:11:30 PDT
It appears to me that this changeset caused assertion failure in Chromium OS and Chromium Mac (possibility others). Here's a stack trace on Chromium OS: http://build.chromium.org/p/chromium/builders/Linux%20Tests%20%28ChromiumOS%20dbg%29%282%29/builds/2774/steps/browser_tests/logs/stdio ASSERTION FAILED: m_key != PTHREAD_KEYS_MAX third_party/WebKit/Source/JavaScriptCore/wtf/ThreadIdentifierDataPthreads.cpp(60) : static WTF::ThreadIdentifier WTF::ThreadIdentifierData::identifier() [7759:7768:0720/203836:986988360721:FATAL:utility_process_host.cc(39)] Check failed: !is_batch_mode_. Backtrace: base::debug::StackTrace::StackTrace() [0x9174f10] logging::LogMessage::~LogMessage() [0x9192f4d] UtilityProcessHost::~UtilityProcessHost() [0xb237a55] ChildProcessHost::OnChildDied() [0x9e77666] BrowserChildProcessHost::OnChildDied() [0xb104192] ChildProcessHost::ListenerHook::OnChannelError() [0x9e77a02] IPC::Channel::ChannelImpl::ClosePipeOnError() [0x9f7197e] IPC::Channel::ChannelImpl::OnFileCanReadWithoutBlocking() [0x9f71665] base::MessagePumpLibevent::FileDescriptorWatcher::OnFileCanReadWithoutBlocking() [0x9161ea8] base::MessagePumpLibevent::OnLibeventNotification() [0x9163cda] event_process_active [0x9829302] event_base_loop [0x9829647] base::MessagePumpLibevent::Run() [0x9163502] MessageLoop::RunInternal() [0x9197afd] MessageLoop::RunHandler() [0x91979d7] MessageLoop::Run() [0x919742b] base::Thread::Run() [0x91d77fb] base::Thread::ThreadMain() [0x91d79cb] base::(anonymous namespace)::ThreadFunc() [0x91d6d62] start_thread [0xf6c7196e] 0xf689bb5e [7759:7768:0720/203836:986988360721:FATAL:utility_process_host.cc(39)] Check failed: !is_batch_mode_. Backtrace: base::debug::StackTrace::StackTrace() [0x9174f10] logging::LogMessage::~LogMessage() [0x9192f4d] UtilityProcessHost::~UtilityProcessHost() [0xb237a55] ChildProcessHost::OnChildDied() [0x9e77666] BrowserChildProcessHost::OnChildDied() [0xb104192] ChildProcessHost::ListenerHook::OnChannelError() [0x9e77a02] IPC::Channel::ChannelImpl::ClosePipeOnError() [0x9f7197e] IPC::Channel::ChannelImpl::OnFileCanReadWithoutBlocking() [0x9f71665] base::MessagePumpLibevent::FileDescriptorWatcher::OnFileCanReadWithoutBlocking() [0x9161ea8] base::MessagePumpLibevent::OnLibeventNotification() [0x9163cda] event_process_active [0x9829302] event_base_loop [0x9829647] base::MessagePumpLibevent::Run() [0x9163502] MessageLoop::RunInternal() [0x9197afd] MessageLoop::RunHandler() [0x91979d7] MessageLoop::Run() [0x919742b] base::Thread::Run() [0x91d77fb] base::Thread::ThreadMain() [0x91d79cb] base::(anonymous namespace)::ThreadFunc() [0x91d6d62] start_thread [0xf6c7196e] 0xf689bb5e
Note You need to log in before you can comment on or make changes to this bug.