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

[Thorsten Kukuk <kukuk at suse dot de>]

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;

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;
        }
    }


Between, I found out that libtirpc is still using select,
while everybody else is using poll() today.
I think it's time to forward port the glibc code here.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)