We should investigate using the Windows thread pool [1] instead of a dedicated thread for WorkQueue on Windows. This would be more similar to how WorkQueue works on Mac, and would hopefully improve performance overall. We'd probably implement this by using ::RegisterWaitForSingleObject. 1. http://msdn.microsoft.com/en-us/library/ms686756(v=VS.85).aspx
<rdar://problem/8247280>
We probably wouldn't want to do this until we had switched to using an I/O completion port in WorkQueue (bug 43148). But I'm not so sure this will work well for us, at least not with ::RegisterWaitForSingleObject. That function will cause a new worker thread to be spawned every time the I/O completion port is signaled, even if another thread is already processing a message from the completion port. This is OK for correctness, as the worker thread will then immediately block on ::GetQueuedCompletionStatus until the other thread(s) finish their work. But it could mean that lots of threads end up sitting around blocked on ::GetQueuedCompletionStatus if it takes longer for a message to be processed than it takes for the completion port to get signaled again.
Created attachment 65721 [details] Use the Windows thread pool instead of a dedicated thread for WorkQueue on Windows
Comment on attachment 65721 [details] Use the Windows thread pool instead of a dedicated thread for WorkQueue on Windows r+
Committed r66506: <http://trac.webkit.org/changeset/66506>
http://trac.webkit.org/changeset/66506 might have broken Leopard Intel Debug (Tests) The following changes are on the blame list: http://trac.webkit.org/changeset/66505 http://trac.webkit.org/changeset/66506 http://trac.webkit.org/changeset/66507 http://trac.webkit.org/changeset/66508 http://trac.webkit.org/changeset/66509