You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The router has functionality for scheduling work to run in the background. This functionality is called the general work handler. It allows code to schedule a function to run on a thread as soon as possible. (Note: this means when the CPU can get around to scheduling a thread to run the function as opposed to a timer that will execute the function after a given delay).
This feature is used to offload work from the calling thread. A good example is when an incoming management request is serviced: the message containing the management request is received by a Proactor I/O thread. Rather than hold the I/O thread while the management operation is executed it is instead scheduled to run outside of the I/O thread via the work handler. This allows the I/O thread to quickly become available to service pending I/O work rather than execute a potentially long-running management operation.
Currently the background work is implemented using a zero-duration timer. This means the background work is executed by the Proactor timer thread. This is undesireable for a couple of reasons: first, zero-length timer durations are inefficient with respect to Proactor scheduling. Second the Proactor timer will use one of the worker threads owned by the Proactor, which effectively prevents that thread from being used for I/O while the background work is running. And lastly these background work handlers can take a long time to run, which blocks all pending timer events from executing in a timely manner (See Issue #1572 for an example).
This issue proposes moving the background work handling from the timer context to its own dedicated pthread.
The text was updated successfully, but these errors were encountered:
The router has functionality for scheduling work to run in the background. This functionality is called the general work handler. It allows code to schedule a function to run on a thread as soon as possible. (Note: this means when the CPU can get around to scheduling a thread to run the function as opposed to a timer that will execute the function after a given delay).
This feature is used to offload work from the calling thread. A good example is when an incoming management request is serviced: the message containing the management request is received by a Proactor I/O thread. Rather than hold the I/O thread while the management operation is executed it is instead scheduled to run outside of the I/O thread via the work handler. This allows the I/O thread to quickly become available to service pending I/O work rather than execute a potentially long-running management operation.
Currently the background work is implemented using a zero-duration timer. This means the background work is executed by the Proactor timer thread. This is undesireable for a couple of reasons: first, zero-length timer durations are inefficient with respect to Proactor scheduling. Second the Proactor timer will use one of the worker threads owned by the Proactor, which effectively prevents that thread from being used for I/O while the background work is running. And lastly these background work handlers can take a long time to run, which blocks all pending timer events from executing in a timely manner (See Issue #1572 for an example).
This issue proposes moving the background work handling from the timer context to its own dedicated pthread.
The text was updated successfully, but these errors were encountered: