On Wed Jan 24 16:29:10 2024 +0000, Jinoh Kang wrote:
Can we move this to `check_wait()`, ideally just after `return STATUS_KERNEL_APC;`? I don't see how the more-processing-required condition is fundamentally different from other signalling conditions that satisfies the wait. Abruptly returning introduces a new "error" mode of `select` request, which will cause the `server_select` loop to be interrupted in a way that I find hard to reason about. For example, it'll interrupt a stream of incoming kernel APCs.[^1] This in particular is probably not an issue, but I'm afraid there are other undiscovered failure modes introduced by this special casing. [^1]: Another thread may call `NtGetContextThread()` while the current thread is still in the `server_select()` loop processing kernel APCs.
New "failure" mode is probably unavoidable, as in the logic of the patch server_select() should fail in this case and indicate that it should be rerun with the context provided and I don't see how that can be done by normal server_select status. This failure should happen before any actual wait because if the thread is being suspended it should provide the context first. It is probably only a matter of where an when the check is performed. Doing that in (the depths of) actual select looks counter intuitive to me and very hard to follow, IMO explicit handling in (select) handler is more straightforward. I think that interrupting stream of system APCs is the desired effect, it may continue with those after providing the context.