Re: libports and interrupted RPCs

Michael Kelly, le jeu. 18 sept. 2025 08:22:57 +0100, a ecrit:
> On 18/09/2025 01:33, Samuel Thibault wrote:
> > >        /* Don't remove 'cancel' from the cancellation list otherwise
> > > 	 any future calls to this function would add it onto a new
> > > 	 cancellation list resulting in pointless additional
> > > 	 cancellation. The cancellation list pointers are safely
> > > 	 managed when the RPC is completed.*/
> > Are they really?
> I believe so, yes.
> > This seems really fragile pointer manipulation to me, even if it's
> > alright now, later developers will possibly get it wrong. I'd be simpler
> 
> I don't see why it is more or less fragile than the current_rpcs list
> management. This new code acts quite similarly to the linking/unlinking
> performed by begin_rpc/end_rpc. The cancellation list links are added in
> ports_interrupt_rpcs and removed in end_rpc.

Ah, I didn't realize that ports_interrupt_rpcs is only advancing in the
linked list, not touching anything. So yes the cleanup is similar to the
current_rpcs list. It however *really* needs to be document what is
happening here as a comment for cl_next/cl_prev, to clearly specify what
code is in charge of adding to the list, interating over the list, and
removing from the list.

> > to just remember that it's already canceled, and let end_rpc clear that
> > at the same time as it unlinks the rpc_info from the port.
> 
> I'm sorry but I don't understand this part. Can you elaborate?

I was thinking that ports_interrupt_rpcs was doing something on the
linked list, so it'd need to record, through a third state, that the
rpc_info got modified for the cancellation.

Samuel