[RFC PATCH glibc 25/34] hurd: Improve reply port handling when exiting signal handlers

[Sergey Bugaev]

On Tue, Apr 11, 2023 at 11:15 PM Samuel Thibault
<samuel.thibault@gnu.org> wrote:
>
> Sergey Bugaev, le mar. 11 avril 2023 10:44:17 +0300, a ecrit:
> > On Tue, Apr 11, 2023 at 1:03 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > > I tend to be very cautious with reply port reuse since it can confuse
> > > servers a lot when e.g. interrupted, so it's generally safer not to try
> > > to reuse them.
> >
> > Huh? Confuse how?
>
> On interruption, it's hard to know whether the server will actually send
> a message on the reply port or not, in the end. So if you re-use a reply
> port but unfortunately the server sent a reply on it in the end, you get
> all reply messages shifted.

Yes, but this is confusing the client, not the server.

But I agree that we must destroy the port on which we have made an RFC
but have not received a reply. This isn't unique to interruptions,
it's a general thing with msg recv timing out.

Sergey