Calls thunk with protection in case kill-allow-protectedis called. The thunk procedure must be ``friendly'' in the following sense: it must return relatively quickly (to keep user-initiated breaks responsive), or wrap long computations with dynamic-enable-break. If thunk does the latter, can-break? must be #t, otherwise it whould be #f.
User breaking is initially disabled as thunk is called. The thunk may be called in the current thread or a new thread. In the latter case, the current thread will wait until the new thread terminates. In either case, the current parameterization will be changed to one that shares all parameter values with the current parameterization except break-enabled, current-custodian, current-exception-handler, and parameterization-branch-handler.
The thread used to call kill-protect can be any thread. In fact, the intent is that this procedure is called when the current thread may be a client program's thread performing sensitive work for the server. See kill-allow-protected for more information.
If thunk creates any threads that are also critical, they should be created using a custodian that is not subject to kills via kill-allow-protected.