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. If there was a need to apply this code change to the other instances of iteration around hurd_thread_cancel, then I would factorise this code to provide one common cancellation list linking function with the unlinking still managed by end_rpc.
The cancellation links have to be managed by end_rpc anyway to support the case that the RPC completes before the attempt is made to cancel in ports_interrupt_rpcs(). That is the biggest benefit in using the linked list rather than a localised array.
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? Regards, Mike.