On Wed, Mar 1, 2023 at 12:09 AM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > > Sergey Bugaev, le mar. 28 févr. 2023 18:53:05 +0300, a ecrit: > > Really, why would it matter whether eip is after > > _hurd_intr_rpc_msg_about_to or not? What if it's 1 instruction before > > that? We skip the call, pretending it was interrupted, but does it > > really matter that we do that — can't we just admit that the signal > > arrived before the call, after all that's exactly how it would look if > > we catch the thread before it enters _hurd_intr_rpc_msg_about_to? > > Yes, but we still need to know whether it was "about to" make an RPC, > to determine whether to interrupt it, or let the code flow until an > cancellation point.
Ah, right, cancellation! That explains it. Thank you for correcting me. I was only thinking of delivering a signal, in which case, yes, it should be fine if we just say that the signal arrived before the RPC and did not interrupt it. But in case of cancellation (as in -- hurd_thread_cancel) we indeed need to not enter the RPC (nor *any* interruptible RPCs?) once we're cancelled. So then indeed we need _hurdsig_abort_rpcs to handle the case where the eip is between the very last check for cancellation and the trap, and make it skip over the trap. Back to my original plan then, luckily I have the code saved in a git stash. * eip < _hurd_intr_rpc_msg_about_to => thread is still to check ss->cancel, so just set ss->cancel = 1; * _hurd_intr_rpc_msg_about_to <= eip < _hurd_intr_rpc_msg_setup_done => thread is still to check eax, so set eax = MACH_SEND_INTERRUPTED; * _hurd_intr_rpc_msg_setup_done <= eip => the thread will not check anything, but we can make it skip over the trap safely, so do that. Sergey
