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
