libbinder: thread count startThreadPool spawn
When startThreadPool is called, it spawns a thread which is
not counted as part of the lazy kernel-started threads.
This was discovered in fuzzers, and the test is updated.
Bug: 286237215
Test: binderLibTest
Change-Id: Ib0fa4484576f9d296b8f57f32ae536b17e5c6497
diff --git a/libs/binder/rust/src/state.rs b/libs/binder/rust/src/state.rs
index cc18741..b35511d 100644
--- a/libs/binder/rust/src/state.rs
+++ b/libs/binder/rust/src/state.rs
@@ -23,6 +23,9 @@
impl ProcessState {
/// Start the Binder IPC thread pool
+ ///
+ /// Starts 1 thread, plus allows the kernel to lazily start up to 'num_threads'
+ /// additional threads as specified by set_thread_pool_max_thread_count.
pub fn start_thread_pool() {
unsafe {
// Safety: Safe FFI
@@ -33,8 +36,7 @@
/// Set the maximum number of threads that can be started in the threadpool.
///
/// By default, after startThreadPool is called, this is 15. If it is called
- /// additional times, it will only prevent the kernel from starting new
- /// threads and will not delete already existing threads.
+ /// additional times, the thread pool size can only be increased.
pub fn set_thread_pool_max_thread_count(num_threads: u32) {
unsafe {
// Safety: Safe FFI
@@ -43,6 +45,9 @@
}
/// Block on the Binder IPC thread pool
+ ///
+ /// This adds additional threads in addition to what is created by
+ /// set_thread_pool_max_thread_count and start_thread_pool.
pub fn join_thread_pool() {
unsafe {
// Safety: Safe FFI