Date: Mon, 17 Jul 2023 19:12:06 +0300
>
> I suppose Yuri's proposal would mean that they can't happen inside a single
> statement, but only between statements. But I see no way to implement that
> without a heavy overhead. Therefore, someone either needs to prove that the
> overhead can be implemented with negligible cost, or then we accept opting
> in
> to this mechanism.
A possible way to reduce overhead is to substitute the thread execution
mechanism by detector-execution mechanism and use a stop point signature
detector.
The main overhead will appear during detection. It is necessary that the
detector be disabled until the request to cancel the thread arrives.
Thread lifetime:
standard execution version *cancel signal* /execution with detecting
version *stop point detection*/ unwinding
We need two thread processing mechanisms
The first mechanism is responsible for: execution + indication of the
"cancellability" of the thread
The second mechanism is responsible for: execution + detection + unwinding
As long as there is no request to cancel, the first mechanism functions
(and while doing that, the overhead from indication is negligible). On
signal to stop the thread, the second mechanism substitutes the first one.
Execution continues with a large overhead due to the operation of the
detector, but
1. The performance of the thread is no longer important to the environment,
the results from it are no longer expected
2. The duration of the overhead from the detector will be relatively small.
If we want to get rid of the overhead in the first mechanism (to reduce
it), we could try the following.
At the stage of compilation, the compiler finds the points between
statements and generates a signature. An index of such signatures for the
procedure is formed. Having a list of signatures, the detector looks for
the corresponding place. The thread runs until the detector finds the
nearest signature in the call sequence, and starts unwinding the stack.
In this case:
The first mechanism is responsible for: execution
The second mechanism is responsible for: execution + detection + unwinding
The compiler is responsible for cancellation points and if the block is
noexcept(true) the compiler just won't generate signatures.
Instead of substitution , we can use a hook that will hang the detector
after a cancel request, but this will be slower.
> I suppose Yuri's proposal would mean that they can't happen inside a single
> statement, but only between statements. But I see no way to implement that
> without a heavy overhead. Therefore, someone either needs to prove that the
> overhead can be implemented with negligible cost, or then we accept opting
> in
> to this mechanism.
A possible way to reduce overhead is to substitute the thread execution
mechanism by detector-execution mechanism and use a stop point signature
detector.
The main overhead will appear during detection. It is necessary that the
detector be disabled until the request to cancel the thread arrives.
Thread lifetime:
standard execution version *cancel signal* /execution with detecting
version *stop point detection*/ unwinding
We need two thread processing mechanisms
The first mechanism is responsible for: execution + indication of the
"cancellability" of the thread
The second mechanism is responsible for: execution + detection + unwinding
As long as there is no request to cancel, the first mechanism functions
(and while doing that, the overhead from indication is negligible). On
signal to stop the thread, the second mechanism substitutes the first one.
Execution continues with a large overhead due to the operation of the
detector, but
1. The performance of the thread is no longer important to the environment,
the results from it are no longer expected
2. The duration of the overhead from the detector will be relatively small.
If we want to get rid of the overhead in the first mechanism (to reduce
it), we could try the following.
At the stage of compilation, the compiler finds the points between
statements and generates a signature. An index of such signatures for the
procedure is formed. Having a list of signatures, the detector looks for
the corresponding place. The thread runs until the detector finds the
nearest signature in the call sequence, and starts unwinding the stack.
In this case:
The first mechanism is responsible for: execution
The second mechanism is responsible for: execution + detection + unwinding
The compiler is responsible for cancellation points and if the block is
noexcept(true) the compiler just won't generate signatures.
Instead of substitution , we can use a hook that will hang the detector
after a cancel request, but this will be slower.
Received on 2023-07-17 16:12:24