[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(_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(_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(_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.
