[grpc-io] Re: gRPC executor threads and timer thread
We're adding a new API to gRPC core for exactly these kinds of situations. Please see https://github.com/grpc/proposal/pull/245 for information on the EventEngine API, I'd appreciate your feedback! In short, if you need fine-grained control over threading/eventing behaviors in gRPC, or want to hook into an external event loop, writing a custom EventEngine will give you that control. Please note this is currently experimental, the team is still working on the reference implementation, and the API will likely undergo some changes in the coming months. Cheers, -aj On Thursday, July 8, 2021 at 12:23:43 PM UTC-7 yas...@google.com wrote: > > 1. What is the purpose of the timer thread? > Throughout the gRPC stack, there are a bunch of deadlines and timeouts > that need to be tracked. The way gRPC Core does this is through timers. It > schedules a closure to be executed when that timer expires and this closure > is run on the timer thread. > > 2. Should everything Just Work™ even if we call > `grpc_timer_manager_set_threading(false)` > No, it won't. :) > On Tuesday, June 29, 2021 at 11:00:36 AM UTC-7 Jonathan Basseri wrote: > >> The context, following from our previous thread, is that we want to add >> grpc endpoints to an existing high-performance application. Our application >> already has extensive control over the allocations and threading on the >> system, so *we would prefer a single-threaded grpc server* that hands >> off async requests to our own work queue. >> >> All of the above seems to be working in Alex's prototype, but we want to >> make sure that stopping these threads is not going to cause problems down >> the line. >> >> 1. What is the purpose of the timer thread? >> 2. Should everything Just Work™ even if we call >> `grpc_timer_manager_set_threading(false)` >> >> Thanks, >> Jonathan >> >> On Monday, June 28, 2021 at 9:19:31 PM UTC-7 Alex Zuo wrote: >> >>> For executor threads, we can use Executor::SetThreadingAll(false) to >>> shut down. If there is no thread, it still works according to the following >>> code. >>> >>> void Executor::Enqueue(grpc_closure* closure, grpc_error_handle error, >>> bool is_short) >>> ... >>> do { >>> retry_push = false; >>> size_t cur_thread_count = >>> static_cast(gpr_atm_acq_load(&num_threads_)); >>> >>> * // If the number of threads is zero(i.e either the executor is not >>> threaded* >>> * // or already shutdown), then queue the closure on the exec context >>> itself* >>> *if (cur_thread_count == 0) {* >>> #ifndef NDEBUG >>> EXECUTOR_TRACE("(%s) schedule %p (created %s:%d) inline", name_, closure, >>> closure->file_created, closure->line_created); >>> #else >>> EXECUTOR_TRACE("(%s) schedule %p inline", name_, closure); >>> #endif >>> grpc_closure_list_append(grpc_core::ExecCtx::Get()->closure_list(), >>> closure, error); >>> return; >>> } >>> >>> For the timer thread, there is a function to shut it down. However I >>> cannot tell what is the impact if there is no such a thread. I also don't >>> know the timer is used. >>> >>> void grpc_timer_manager_set_threading(bool enabled); >>> >>> Anybody has any insight? >>> >>> Thanks, >>> Alex >>> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/3f0c43a4-b25e-4674-9c29-6deee0771fb7n%40googlegroups.com.
[grpc-io] Re: gRPC executor threads and timer thread
1. What is the purpose of the timer thread? Throughout the gRPC stack, there are a bunch of deadlines and timeouts that need to be tracked. The way gRPC Core does this is through timers. It schedules a closure to be executed when that timer expires and this closure is run on the timer thread. 2. Should everything Just Work™ even if we call `grpc_timer_manager_set_threading(false)` No, it won't. :) On Tuesday, June 29, 2021 at 11:00:36 AM UTC-7 Jonathan Basseri wrote: > The context, following from our previous thread, is that we want to add > grpc endpoints to an existing high-performance application. Our application > already has extensive control over the allocations and threading on the > system, so *we would prefer a single-threaded grpc server* that hands off > async requests to our own work queue. > > All of the above seems to be working in Alex's prototype, but we want to > make sure that stopping these threads is not going to cause problems down > the line. > > 1. What is the purpose of the timer thread? > 2. Should everything Just Work™ even if we call > `grpc_timer_manager_set_threading(false)` > > Thanks, > Jonathan > > On Monday, June 28, 2021 at 9:19:31 PM UTC-7 Alex Zuo wrote: > >> For executor threads, we can use Executor::SetThreadingAll(false) to shut >> down. If there is no thread, it still works according to the following code. >> >> void Executor::Enqueue(grpc_closure* closure, grpc_error_handle error, >> bool is_short) >> ... >> do { >> retry_push = false; >> size_t cur_thread_count = >> static_cast(gpr_atm_acq_load(&num_threads_)); >> >> * // If the number of threads is zero(i.e either the executor is not >> threaded* >> * // or already shutdown), then queue the closure on the exec context >> itself* >> *if (cur_thread_count == 0) {* >> #ifndef NDEBUG >> EXECUTOR_TRACE("(%s) schedule %p (created %s:%d) inline", name_, closure, >> closure->file_created, closure->line_created); >> #else >> EXECUTOR_TRACE("(%s) schedule %p inline", name_, closure); >> #endif >> grpc_closure_list_append(grpc_core::ExecCtx::Get()->closure_list(), >> closure, error); >> return; >> } >> >> For the timer thread, there is a function to shut it down. However I >> cannot tell what is the impact if there is no such a thread. I also don't >> know the timer is used. >> >> void grpc_timer_manager_set_threading(bool enabled); >> >> Anybody has any insight? >> >> Thanks, >> Alex >> > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4d9f8c2a-6725-4d45-9647-60571d44f266n%40googlegroups.com.
[grpc-io] Re: gRPC executor threads and timer thread
The context, following from our previous thread, is that we want to add grpc endpoints to an existing high-performance application. Our application already has extensive control over the allocations and threading on the system, so *we would prefer a single-threaded grpc server* that hands off async requests to our own work queue. All of the above seems to be working in Alex's prototype, but we want to make sure that stopping these threads is not going to cause problems down the line. 1. What is the purpose of the timer thread? 2. Should everything Just Work™ even if we call `grpc_timer_manager_set_threading(false)` Thanks, Jonathan On Monday, June 28, 2021 at 9:19:31 PM UTC-7 Alex Zuo wrote: > For executor threads, we can use Executor::SetThreadingAll(false) to shut > down. If there is no thread, it still works according to the following code. > > void Executor::Enqueue(grpc_closure* closure, grpc_error_handle error, > bool is_short) > ... > do { > retry_push = false; > size_t cur_thread_count = > static_cast(gpr_atm_acq_load(&num_threads_)); > > * // If the number of threads is zero(i.e either the executor is not > threaded* > * // or already shutdown), then queue the closure on the exec context > itself* > *if (cur_thread_count == 0) {* > #ifndef NDEBUG > EXECUTOR_TRACE("(%s) schedule %p (created %s:%d) inline", name_, closure, > closure->file_created, closure->line_created); > #else > EXECUTOR_TRACE("(%s) schedule %p inline", name_, closure); > #endif > grpc_closure_list_append(grpc_core::ExecCtx::Get()->closure_list(), > closure, error); > return; > } > > For the timer thread, there is a function to shut it down. However I > cannot tell what is the impact if there is no such a thread. I also don't > know the timer is used. > > void grpc_timer_manager_set_threading(bool enabled); > > Anybody has any insight? > > Thanks, > Alex > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/0a66b4c6-c36f-4576-b015-5d47de109e77n%40googlegroups.com.