Michael Kelly, le lun. 08 sept. 2025 07:05:39 +0100, a ecrit: > The changes I suggest do not access the list in this way after the mutex has > been released. The next iteration restarts the scan from the (possibly new) > head of the list.
Ah, it restarts over on each cancellation. That's really bad asymptotic quadratic complexity. That will hit us sooner or later. > Any RPCs added (or removed) from the list later will not be considered > for cancellation. Ah, ok. > I don't understand the suggestion about not re-cancelling a thread already > in cancellation due to a signal. I'm not saying only about signals, but also about interruption: our issue is that ports_interrupt_rpcs calls hurd_thread_cancel which cancels the thread, and for that calls _hurdsig_abort_rpcs which might get stuck inside the __interrupt_operation() call. If in hurd_thread_cancel we check ss->cancel and avoid calling _hurdsig_abort_rpcs again, we won't call __interrupt_operation() again and get stuck there. > That occurs within the originating client but isn't the storm of > interruptions being generated on the server side? On the server side there can be a cascade of interruptions too, yes, but at least it wouldn't pile cancellations. Samuel
