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: Thorsten Kukuk <kukuk at suse dot de>
- To: Chuck Lever <chucklever at gmail dot com>
- Cc: libc-alpha at sourceware dot org, libtirpc List <libtirpc-devel at lists dot sourceforge dot net>
- Date: Thu, 9 Jul 2015 12:02:59 +0200
- 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> <CDBA20DE-E2B9-4206-B169-DB405C367691 at gmail dot com>
On Wed, Jul 08, Chuck Lever wrote:
> > On Jul 8, 2015, at 7:52 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> > 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.
I submitted a patch to fix that.
> 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().
Even Solaris is using poll() and not select(). Looks like
glibcs svc_pollfd/svc_max_pollfd is coming from Solaris.
I will create a patch, but that will be binary incompatible :(
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)