This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code
- From: Chuck Lever <chucklever at gmail dot com>
- To: Thorsten Kukuk <kukuk at suse dot de>
- Cc: libc-alpha at sourceware dot org, libtirpc List <libtirpc-devel at lists dot sourceforge dot net>
- Date: Wed, 8 Jul 2015 14:05:01 -0400
- Subject: Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code
- Authentication-results: sourceware.org; auth=none
- References: <20150624124457 dot GA7930 at suse dot de> <20150625100529 dot GQ17734 at vapier> <20150706123140 dot GB11315 at suse dot de> <8EB99EE2-ADC5-454B-8576-C40EB6AD4252 at gmail dot com> <20150708115224 dot GA3021 at suse dot de>
> 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