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. > Any other code that would temporarily set esp to below the actual tip > of the stack — no RPCing needs to be involved — would need similar > special-casing in these two files. That's not supposed to happen. Really it should have never be handled. But properly supporting cancellation is a reason for the kludge. > And so since 1d20f33ff4fb634310f27493b7b87d0b20f4a0b0 has dropped the > root cause of the kludge, _all of this code_ can be dropped too. > > I will un-implement that and see whether that really works; in the > meantime — does this make sense? You'll most probably not easily meet the cases that matter: a cancelation or interruption that is triggered right at the wrong time, i.e. between the C check for cancellation etc., and the lcall. Samuel
