Re: libports and interrupted RPCs

[Samuel Thibault <sthibault@debian.org>]

Michael Kelly, le mer. 17 sept. 2025 20:58:56 +0100, a ecrit:
> My solution adds cl_prev and cl_next list item pointers to each
> rpc_info so that the ones to cancel can be linked together to form a
> separate cancellation list. This acts the part of the array you refer
> to.

That should be fine indeed, except:

>   while (cancel)
>     {
>       thread_t thread = cancel->thread;
> 
>       /* setting 'cancelling' guarantees that the 'cancel' data
> 	 structure remains accessible after the _ports_lock is
> 	 released and reacquired. */
>       cancel->cancelling = TRUE;
>
>       pthread_mutex_unlock (&_ports_lock);
>       hurd_thread_cancel (thread);
>       pthread_mutex_lock (&_ports_lock);
> 
>       _ports_record_interruption (cancel);
>       cancel->cancelling = FALSE;
>       cancel = cancel->cl_next;
> 
>       /* 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?

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
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.

>       pthread_cond_broadcast(&_ports_block);
>     }
> 
>   pthread_mutex_unlock (&_ports_lock);
> }

Samuel