bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port


From: Samuel Thibault
Subject: Re: [RFC PATCH glibc 26/34] hurd: Remove __hurd_local_reply_port
Date: Tue, 11 Apr 2023 00:35:52 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Samuel Thibault, le mar. 11 avril 2023 00:07:43 +0200, a ecrit:
> Sergey Bugaev, le dim. 19 mars 2023 18:10:09 +0300, a ecrit:
> >  /* Called by MiG to deallocate the reply port.  */
> >  void
> > -__mig_dealloc_reply_port (mach_port_t arg)
> > +__mig_dealloc_reply_port (mach_port_t port)
> >  {
> > -  mach_port_t port = __hurd_local_reply_port;
> > -  __hurd_local_reply_port = MACH_PORT_NULL;        /* So the mod_refs RPC 
> > won't use it.  */
> > +  set_reply_port (MACH_PORT_NULL); /* So the mod_refs RPC won't use it.  */
> >  
> >    if (MACH_PORT_VALID (port))
> >      __mach_port_mod_refs (__mach_task_self (), port,
> 
> I believe we still want to use
> 
>  mach_port_t port = get_reply_port();
> 
> because the caller might not know whether its port is still valid
> or not, e.g. when a signal interrupted the RPC and thus we had to
> deallocate the reply port to make sure the server doesn't get confused.
> In that case the caller will still have the old reply port name, which
> we don't want to reallocate since it might already have been reused for

                   deallocate

> something else.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]