From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 2219C385BF93 for ; Wed, 11 Aug 2021 00:53:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2219C385BF93 Received: from mail-pl1-f198.google.com (mail-pl1-f198.google.com [209.85.214.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-284-hOqQ9hJhOt-t3jWX2sYzxg-1; Tue, 10 Aug 2021 20:53:43 -0400 X-MC-Unique: hOqQ9hJhOt-t3jWX2sYzxg-1 Received: by mail-pl1-f198.google.com with SMTP id f4-20020a170902ce84b029012ccdab6e58so258098plg.0 for ; Tue, 10 Aug 2021 17:53:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=izmkBnmfpVrTPNCVVzVIRSXdiCeOFUjzdqSqt52a4z4=; b=qG0iLG9SC6tieJ+SWdArkkQn198oOcKakklJm6VjVyF0qfddqjC71yKPw6Yi2QEZOE IJj18z9WWLw0lZqHYvzqAcUofpBBuSNDe8pJWEGfcc7U9XBmOV7FOorbMrxumGEaqeoy iov54EmbVPvqDUeIrmpislJGROe4djSSodoPg0CCBJeRrkkhYbVasLf3Eq2rR2p8jtdp EN5m+bIxOo/vZ7zW9HOv8ceJJzKp93XCqm27w2EUygsNtJH0S0SIuEq1TKNx/gfGjPK7 IPGOwKmIsvqHvGMc8fcXTp0ojt+BG8Z60DSgVStGzNu8IOYTWNVcFJRqTlOwhL6Ltefv v1iQ== X-Gm-Message-State: AOAM531Et/xM5iPepJwuDO+J8SaLqCOSlwHoCH150eAJIvAK4DFmDU1b hScFhJVa0dfHC4F3ZML6c3Wkbjgt0BkEi4oET8PkdhZMJz5rmAL9q3Z8l+N052SGbPhf5QK9RSf NB2J8wZDojgJ6JlT4kEZH X-Received: by 2002:a63:3c7:: with SMTP id 190mr34825pgd.240.1628643222089; Tue, 10 Aug 2021 17:53:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzknE6qofA9pXP1pmSliZQN5qqUDkuT33tHi/5WKXvHkuVGcqAUfYy3ZIuCcovpc8DZN+98Ug== X-Received: by 2002:a63:3c7:: with SMTP id 190mr34806pgd.240.1628643221841; Tue, 10 Aug 2021 17:53:41 -0700 (PDT) Received: from mickey.themaw.net ([180.150.83.225]) by smtp.gmail.com with ESMTPSA id n32sm3543071pgl.69.2021.08.10.17.53.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Aug 2021 17:53:41 -0700 (PDT) Subject: Re: Building sunrpc from glibc source To: "Binello, Severino" , "libc-alpha@sourceware.org" , "fweimer@redhat.com" , "Marusic, Aljosa" References: <88153f7a-5c2b-779d-16b5-6fcd00abcd07@redhat.com> From: Ian Kent Message-ID: <8e080640-21f1-5da3-3617-2a137faf54cb@redhat.com> Date: Wed, 11 Aug 2021 08:53:36 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 00:53:47 -0000 On 11/8/21 1:47 am, Binello, Severino wrote: > Hello Ian and Florian > > Thanks for the feedback, its much appreciated > Unfortunately Im not the best person to be asking the questions or > providing the info > My role with our communication code right now is to get it to build > > I am reaching out to the developer of our rpc based code to see if he > can provide > a better picture and provide  further information. > So I am including Al Marusic in this email thread. Ok. Don't get me wrong, I do understand the potential difficulty changing to libtirpc. But glibc rpc has been on the chopping block for years so there's been plenty of time to investigate and change. At the very least some analysis needs to be done about the application rpc usage to understand where the difficulties are. Certainly, if you use low level rpc calls (in order to take control of timeouts and such) the work would be substantial but if your using higher level rpc calls it might not be so bad. TBH the application I maintain does need to use lower level rpc calls so using libtirpc was a significant change for me, but that was a long time ago now. Bottom line is that libtirpc is thread safe but it depends on the rpc calls that are used. Ian > > Thanks again! > -Sev > > ------------------------------------------------------------------------ > *From:* Ian Kent > *Sent:* Friday, August 6, 2021 8:27 PM > *To:* Binello, Severino ; libc-alpha@sourceware.org > > *Subject:* Re: Building sunrpc from glibc source > > On 6/8/21 8:07 pm, Ian Kent wrote: > > On 6/8/21 7:12 am, Binello, Severino via Libc-alpha wrote: > >> Hello > >> > >>    As of RedHat 8, the sunrpc is no longer included with glibc shared > >> object library. > >> Unfortunately, our communications software would require extensive > >> redesign in order to use tirpc. > > > > For example? > > > > Can you describe the sort of challenges you have doing this please. > > > > > >> As such, we are looking into an alternative approach where we just > >> build the sunrpc portion from the glibc source tar file. > >> However, running into difficulties separating it out. > >> Can you recommend a method for just building the sunrpc code ? > > > > It's worth understanding what might be needed in order to use libtirpc > > > > first. > > > > > >> > >> Thanks Much > >> -Sev > >> > >> ps: Below is the reason why our code is incompatible with the tirpc > >> design > >> with old glibc every RPC server runs in its own thread, > >> with tirpc library there can be only one RPC server per program. > >> See: > >> from svc.c of tirpc library: > >> > >> static struct svc_callout /* removed declaration */ *svc_head; > >> > >> from svc.c of glibc-2.25: > >> > >> #ifdef _RPC_THREAD_SAFE_ > >> #define svc_head RPC_THREAD_VARIABLE(svc_head_s) > >> #else > >> static struct svc_callout *svc_head; > >> #endif > >> > >> As you can see, if RPC_THREAD_SAFE_ is defined, > >> svc_head is per thread variable. > > > > I think I have some quick and nasty multi-thread libtirpc svc code > > > > kicking around somewhere (if I can find it now). It might be worth > > > > cleaning that up and maybe enhancing it a little, or maybe it's broken > > > > I don't know, but I'd recommend looking at that first, if there's not > > > > to many other problems to deal with. > > Actually it looks like this was multi-threaded io not multi-threaded > servers. > > > But I'm not sure that you can't register multiple services in both glibc > > and libtirpc, it's just that it's not thread safe to do so in glibc. > > > Maybe I don't understand what your doing, explain it please. > > > Why do you need a separate services list for each thread rather than a > > library global lock protected services list as in libtirpc? > > > Ian >