Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Chuck Lever <chucklever at gmail dot com>]

> On Jul 8, 2015, at 7:52 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> 
> 
> 
> Hi Chuck,
> 
> On Mon, Jul 06, Chuck Lever wrote:
> 
> 
>>> On Jul 6, 2015, at 8:31 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> 
>>> With my latest TI-RPC patches, I only see two remaining problems, 
>>> both not solveable and needs adjustement in the applications:
>>> 1. programs trying to hook into svc_run().
>>> 2. different naming of some variables.
>> 
> 
> For 2:
> sunrpc: rpc/svc.h, struct SVCXPRT is using int xp_sock;
> tirpc: rpc/svc.h, struct SVCXPRT is using int xp_fd;

Solaris has this in rpc/svc.h:

struct __svcxprt {
        int             xp_fd;
#define xp_sock         xp_fd
        ushort_t        xp_port;

That macro seems reasonable to add to libtirpc’s tirpc/rpc/svc.h.


> For 1:
> We are missing svc_max_pollfd. glibc and Solaris have that.
> Something "pseudo" code from the NIS+ code, but some rstatd 
> implementations are doing something similar:
> 
>  for (;;)
>    {
>      struct pollfd my_pollfd[svc_max_pollfd];
>      int i;
> 
>      for (i = 0; i < svc_max_pollfd; ++i)
>        {
>          my_pollfd[i].fd = svc_pollfd[i].fd;
>          my_pollfd[i].events = svc_pollfd[i].events;
>          my_pollfd[i].revents = 0;
>        }
> 
>      switch (i = TEMP_FAILURE_RETRY (poll (my_pollfd, svc_max_pollfd,
>                                              25*1000)))
>        {
>        case -1:
>          return NIS_CBERROR;
>        case 0:
>          if (clnt_call (...
>          break;
>        default:
>          svc_getreq_poll (my_pollfd, i);
>          if (data->nomore)
>            return data->result;
>        }
>    }

There is no svc_pollfd array either.


> Between, I found out that libtirpc is still using select,
> while everybody else is using poll() today.

The FreeBSD TI-RPC code, which is a direct ancestor of our
libtirpc, still uses select(3) in svc_run().


> I think it's time to forward port the glibc code here.

That would provide svc_pollfd and svc_max_pollfd. I can see a
strong compatibility argument for forward porting.


--
Chuck Lever
chucklever@gmail.com