Undelivered Mail Returned to Sender

[MAILER-DAEMON (Mail Delivery System)]

[-- Attachment #1: Notification --]
[-- Type: text/plain, Size: 593 bytes --]

This is the mail system at host fx405.security-mail.net.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<mpoulhies@kalray.eu>: host zimbra2.kalray.eu[195.135.97.26] said: 550 5.1.1
    <mpoulhies@kalray.eu>: Recipient address rejected: User unknown in virtual
    mailbox table (in reply to RCPT TO command)

[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Size: 464 bytes --]

[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Size: 9672 bytes --]

From: Ian Kent via Libc-alpha <libc-alpha@sourceware.org>
To: "Binello, Severino" <sev@bnl.gov>, libc-alpha@sourceware.org, fweimer@redhat.com, "Marusic, Aljosa" <marusic@bnl.gov>
Subject: Re: Building sunrpc from glibc source
Date: Wed, 11 Aug 2021 08:53:36 +0800
Message-ID: <8e080640-21f1-5da3-3617-2a137faf54cb@redhat.com>


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 <ikent@redhat.com>
> *Sent:* Friday, August 6, 2021 8:27 PM
> *To:* Binello, Severino <sev@bnl.gov>; libc-alpha@sourceware.org 
> <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
>


To declare a filtering error, please use the following link : https://www.security-mail.net/reporter.php?mid=159c2.61131fac.6ff3b.0&r=mpoulhies%40kalray.eu&s=libc-alpha-bounces%2Bmpoulhies%3Dkalray.eu%40sourceware.org&o=Re%3A+Building+sunrpc+from+glibc+source&verdict=C&c=0198a7272b86f871dfb7eb689d2f929c9aeddf13