Start of thread pool implementation

Start of thread pool implementation

This the initial commit for adding a thread pool to the Dart
server. For now it is hidden behind a flag (--enable_thread_pool)
and when enabled just starts up and processes 100 void tasks.

Mac OS implementation is not tested and Windows implementation is
still pending.

As we are currently not sharing anything between bin/ and vm/ I
have just used pthread calls directly in the Linux and Mac OS
implementation code. However with Monitor and Thread classes from
vm/ the thread pool could be written platform independently. This
can always be changed later.

R=ager@google.com

BUG=
TEST=

Committed: https://code.google.com/p/dart/source/detail?r=2946

[Mads Ager (google), 2012-01-04 14:32:46]

lgtm

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool.cc
File runtime/bin/thread_pool.cc (right):

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool.cc#n...
runtime/bin/thread_pool.cc:30: printf("Thread pool thread started\n");
Should we remove this printing or add a --trace-thread-pool flag?

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_linu...
File runtime/bin/thread_pool_linux.cc (right):

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_linu...
runtime/bin/thread_pool_linux.cc:27: ASSERT(tail_ == NULL);
Maybe not assert here? We don't really care about tail in this case and it is
only NULL in release mode.

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_linu...
runtime/bin/thread_pool_linux.cc:48: #ifdef DEBUG
Maybe just

ASSERT(head_ != NULL || tail_ == result)

and not change tail_?

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_macos.h
File runtime/bin/thread_pool_macos.h (right):

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_maco...
runtime/bin/thread_pool_macos.h:33: static const int kMaxThreadPoolSize = 16;
You could set this in the constructor to Platform::NumberOfProcessors from
bin/platform.h as well. Available on all platforms.

That of course means that you have to dynamically allocate threads_ as well.

[Søren Gjesse, 2012-01-04 15:15:07]

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool.cc
File runtime/bin/thread_pool.cc (right):

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool.cc#n...
runtime/bin/thread_pool.cc:30: printf("Thread pool thread started\n");
On 2012/01/04 14:32:46, Mads Ager wrote:
> Should we remove this printing or add a --trace-thread-pool flag?

Added flag --trace_thread_pool.

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_linu...
File runtime/bin/thread_pool_linux.cc (right):

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_linu...
runtime/bin/thread_pool_linux.cc:27: ASSERT(tail_ == NULL);
On 2012/01/04 14:32:46, Mads Ager wrote:
> Maybe not assert here? We don't really care about tail in this case and it is
> only NULL in release mode.

Right, removed the asserts.

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_linu...
runtime/bin/thread_pool_linux.cc:48: #ifdef DEBUG
On 2012/01/04 14:32:46, Mads Ager wrote:
> Maybe just
> 
> ASSERT(head_ != NULL || tail_ == result)
> 
> and not change tail_?

Done.

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_macos.h
File runtime/bin/thread_pool_macos.h (right):

http://codereview.chromium.org/8983017/diff/4002/runtime/bin/thread_pool_maco...
runtime/bin/thread_pool_macos.h:33: static const int kMaxThreadPoolSize = 16;
On 2012/01/04 14:32:46, Mads Ager wrote:
> You could set this in the constructor to Platform::NumberOfProcessors from
> bin/platform.h as well. Available on all platforms.
> 
> That of course means that you have to dynamically allocate threads_ as well.

Removed the constant alltogether. threads_ is now dynamically allocated, and the
size is fully controlled by the thread pool implementation.

[Ivan Posva, 2012-01-04 17:26:34]

Overall I am not convinced this is the right way to approach a thread pool. Can
we please discuss the design and plan before moving any further?

Thanks,
-Ivan

http://codereview.chromium.org/8983017/diff/2003/runtime/bin/eventhandler_lin...
File runtime/bin/eventhandler_linux.cc (right):

http://codereview.chromium.org/8983017/diff/2003/runtime/bin/eventhandler_lin...
runtime/bin/eventhandler_linux.cc:376: for (int i = 0; i < 100; i++) {
This is non-sensical. Please make this into a proper testcase.