Re: libports and interrupted RPCs

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