|
3 | 3 | module Concurrent
|
4 | 4 |
|
5 | 5 | if Concurrent.on_jruby?
|
6 |
| - |
7 | 6 | require 'concurrent/executor/java_fixed_thread_pool'
|
| 7 | + end |
| 8 | + |
| 9 | + FixedThreadPoolImplementation = case |
| 10 | + when Concurrent.on_jruby? |
| 11 | + JavaFixedThreadPool |
| 12 | + else |
| 13 | + RubyFixedThreadPool |
| 14 | + end |
| 15 | + private_constant :FixedThreadPoolImplementation |
8 | 16 |
|
9 |
| - # @!macro [attach] fixed_thread_pool |
10 |
| - # |
11 |
| - # A thread pool with a set number of threads. The number of threads in the pool |
12 |
| - # is set on construction and remains constant. When all threads are busy new |
13 |
| - # tasks `#post` to the thread pool are enqueued until a thread becomes available. |
14 |
| - # Should a thread crash for any reason the thread will immediately be removed |
15 |
| - # from the pool and replaced. |
16 |
| - # |
17 |
| - # The API and behavior of this class are based on Java's `FixedThreadPool` |
18 |
| - # |
19 |
| - # @see Concurrent::RubyFixedThreadPool |
20 |
| - # @see Concurrent::JavaFixedThreadPool |
21 |
| - # |
22 |
| - # @!macro [attach] thread_pool_options |
23 |
| - # |
24 |
| - # Thread pools support several configuration options: |
25 |
| - # |
26 |
| - # * `idletime`: The number of seconds that a thread may be idle before being reclaimed. |
27 |
| - # * `max_queue`: The maximum number of tasks that may be waiting in the work queue at |
28 |
| - # any one time. When the queue size reaches `max_queue` subsequent tasks will be |
29 |
| - # rejected in accordance with the configured `fallback_policy`. |
30 |
| - # * `auto_terminate`: When true (default) an `at_exit` handler will be registered which |
31 |
| - # will stop the thread pool when the application exits. See below for more information |
32 |
| - # on shutting down thread pools. |
33 |
| - # * `fallback_policy`: The policy defining how rejected tasks are handled. |
34 |
| - # |
35 |
| - # Three fallback policies are supported: |
36 |
| - # |
37 |
| - # * `:abort`: Raise a `RejectedExecutionError` exception and discard the task. |
38 |
| - # * `:discard`: Discard the task and return false. |
39 |
| - # * `:caller_runs`: Execute the task on the calling thread. |
40 |
| - # |
41 |
| - # **Shutting Down Thread Pools** |
42 |
| - # |
43 |
| - # Killing a thread pool while tasks are still being processed, either by calling |
44 |
| - # the `#kill` method or at application exit, will have unpredictable results. There |
45 |
| - # is no way for the thread pool to know what resources are being used by the |
46 |
| - # in-progress tasks. When those tasks are killed the impact on those resources |
47 |
| - # cannot be predicted. The *best* practice is to explicitly shutdown all thread |
48 |
| - # pools using the provided methods: |
49 |
| - # |
50 |
| - # * Call `#shutdown` to initiate an orderly termination of all in-progress tasks |
51 |
| - # * Call `#wait_for_termination` with an appropriate timeout interval an allow |
52 |
| - # the orderly shutdown to complete |
53 |
| - # * Call `#kill` *only when* the thread pool fails to shutdown in the allotted time |
54 |
| - # |
55 |
| - # On some runtime platforms (most notably the JVM) the application will not |
56 |
| - # exit until all thread pools have been shutdown. To prevent applications from |
57 |
| - # "hanging" on exit all thread pools include an `at_exit` handler that will |
58 |
| - # stop the thread pool when the application exists. This handler uses a brute |
59 |
| - # force method to stop the pool and makes no guarantees regarding resources being |
60 |
| - # used by any tasks still running. Registration of this `at_exit` handler can be |
61 |
| - # prevented by setting the thread pool's constructor `:auto_terminate` option to |
62 |
| - # `false` when the thread pool is created. All thread pools support this option. |
63 |
| - # |
64 |
| - # ```ruby |
65 |
| - # pool1 = Concurrent::FixedThreadPool.new(5) # an `at_exit` handler will be registered |
66 |
| - # pool2 = Concurrent::FixedThreadPool.new(5, auto_terminate: false) # prevent `at_exit` handler registration |
67 |
| - # ``` |
68 |
| - # |
69 |
| - # @note Failure to properly shutdown a thread pool can lead to unpredictable results. |
70 |
| - # Please read *Shutting Down Thread Pools* for more information. |
71 |
| - # |
72 |
| - # @note When running on the JVM (JRuby) this class will inherit from `JavaThreadPoolExecutor`. |
73 |
| - # On all other platforms it will inherit from `RubyThreadPoolExecutor`. |
74 |
| - # |
75 |
| - # @see Concurrent::RubyThreadPoolExecutor |
76 |
| - # @see Concurrent::JavaThreadPoolExecutor |
77 |
| - # |
78 |
| - # @see http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html Java Tutorials: Thread Pools |
79 |
| - # @see http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html Java Executors class |
80 |
| - # @see http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html Java ExecutorService interface |
81 |
| - # @see http://ruby-doc.org//core-2.2.0/Kernel.html#method-i-at_exit Kernel#at_exit |
82 |
| - class FixedThreadPool < JavaFixedThreadPool |
83 |
| - end |
84 |
| - else |
85 |
| - # @!macro fixed_thread_pool |
86 |
| - # @!macro thread_pool_options |
87 |
| - class FixedThreadPool < RubyFixedThreadPool |
88 |
| - end |
| 17 | + # @!macro [attach] fixed_thread_pool |
| 18 | + # |
| 19 | + # A thread pool with a set number of threads. The number of threads in the pool |
| 20 | + # is set on construction and remains constant. When all threads are busy new |
| 21 | + # tasks `#post` to the thread pool are enqueued until a thread becomes available. |
| 22 | + # Should a thread crash for any reason the thread will immediately be removed |
| 23 | + # from the pool and replaced. |
| 24 | + # |
| 25 | + # The API and behavior of this class are based on Java's `FixedThreadPool` |
| 26 | + # |
| 27 | + # @see Concurrent::RubyFixedThreadPool |
| 28 | + # @see Concurrent::JavaFixedThreadPool |
| 29 | + # |
| 30 | + # @!macro [attach] thread_pool_options |
| 31 | + # |
| 32 | + # Thread pools support several configuration options: |
| 33 | + # |
| 34 | + # * `idletime`: The number of seconds that a thread may be idle before being reclaimed. |
| 35 | + # * `max_queue`: The maximum number of tasks that may be waiting in the work queue at |
| 36 | + # any one time. When the queue size reaches `max_queue` subsequent tasks will be |
| 37 | + # rejected in accordance with the configured `fallback_policy`. |
| 38 | + # * `auto_terminate`: When true (default) an `at_exit` handler will be registered which |
| 39 | + # will stop the thread pool when the application exits. See below for more information |
| 40 | + # on shutting down thread pools. |
| 41 | + # * `fallback_policy`: The policy defining how rejected tasks are handled. |
| 42 | + # |
| 43 | + # Three fallback policies are supported: |
| 44 | + # |
| 45 | + # * `:abort`: Raise a `RejectedExecutionError` exception and discard the task. |
| 46 | + # * `:discard`: Discard the task and return false. |
| 47 | + # * `:caller_runs`: Execute the task on the calling thread. |
| 48 | + # |
| 49 | + # **Shutting Down Thread Pools** |
| 50 | + # |
| 51 | + # Killing a thread pool while tasks are still being processed, either by calling |
| 52 | + # the `#kill` method or at application exit, will have unpredictable results. There |
| 53 | + # is no way for the thread pool to know what resources are being used by the |
| 54 | + # in-progress tasks. When those tasks are killed the impact on those resources |
| 55 | + # cannot be predicted. The *best* practice is to explicitly shutdown all thread |
| 56 | + # pools using the provided methods: |
| 57 | + # |
| 58 | + # * Call `#shutdown` to initiate an orderly termination of all in-progress tasks |
| 59 | + # * Call `#wait_for_termination` with an appropriate timeout interval an allow |
| 60 | + # the orderly shutdown to complete |
| 61 | + # * Call `#kill` *only when* the thread pool fails to shutdown in the allotted time |
| 62 | + # |
| 63 | + # On some runtime platforms (most notably the JVM) the application will not |
| 64 | + # exit until all thread pools have been shutdown. To prevent applications from |
| 65 | + # "hanging" on exit all thread pools include an `at_exit` handler that will |
| 66 | + # stop the thread pool when the application exists. This handler uses a brute |
| 67 | + # force method to stop the pool and makes no guarantees regarding resources being |
| 68 | + # used by any tasks still running. Registration of this `at_exit` handler can be |
| 69 | + # prevented by setting the thread pool's constructor `:auto_terminate` option to |
| 70 | + # `false` when the thread pool is created. All thread pools support this option. |
| 71 | + # |
| 72 | + # ```ruby |
| 73 | + # pool1 = Concurrent::FixedThreadPool.new(5) # an `at_exit` handler will be registered |
| 74 | + # pool2 = Concurrent::FixedThreadPool.new(5, auto_terminate: false) # prevent `at_exit` handler registration |
| 75 | + # ``` |
| 76 | + # |
| 77 | + # @note Failure to properly shutdown a thread pool can lead to unpredictable results. |
| 78 | + # Please read *Shutting Down Thread Pools* for more information. |
| 79 | + # |
| 80 | + # @note When running on the JVM (JRuby) this class will inherit from `JavaFixedThreadPool`. |
| 81 | + # On all other platforms it will inherit from `RubyFixedThreadPool`. |
| 82 | + # |
| 83 | + # @see Concurrent::RubyFixedThreadPool |
| 84 | + # @see Concurrent::JavaFixedThreadPool |
| 85 | + # |
| 86 | + # @see http://docs.oracle.com/javase/tutorial/essential/concurrency/pools.html Java Tutorials: Thread Pools |
| 87 | + # @see http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Executors.html Java Executors class |
| 88 | + # @see http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutorService.html Java ExecutorService interface |
| 89 | + # @see http://ruby-doc.org//core-2.2.0/Kernel.html#method-i-at_exit Kernel#at_exit |
| 90 | + class FixedThreadPool < FixedThreadPoolImplementation |
89 | 91 | end
|
90 | 92 | end
|
0 commit comments