Bug 62969 - Can not share RPC client handle between threads
Summary: Can not share RPC client handle between threads
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-04-08 17:33 UTC by Need Real Name
Modified: 2016-11-24 15:07 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2003-04-24 00:06:42 UTC

Attachments (Terms of Use)

Description Need Real Name 2002-04-08 17:33:55 UTC
Description of Problem:
If I call authnone_create() in one thread, and then try to use
it via AUTH_MARSHAL in another thread, the AUTH_MARSHAL call
fails because authnone_private is grabbed from that thread's
local state (where it's still null).  

Version-Release number of selected component (if applicable):

How Reproducible:

Steps to Reproduce:
1. Create a multi threaded program that does RPCs with a shared client handle

Actual Results:

Expected Results:

Additional Information:
Looks like each thread needs to do an authnone_create() or something similiar 
to initialize this.  Shouldn't it just default?

Comment 1 Jakub Jelinek 2002-04-09 12:35:28 UTC
Why do you think it is a bug?
RPC is not shared between threads, each one has its own.

Comment 2 Need Real Name 2002-04-09 15:24:22 UTC
1.  The behavior was different in the glibc delivered with Red Hat 6.2.
2.  The RPC client handle is a global handle in a library that is shared among 
a single applications threads.  The first call into the library will cause the 
handle to be created.  Only this thread can use the handle.  If the other 
threads want to use the handle, they have to do an some form of authentication 
instead of picking up the default 'authnone' from the 'clnt_create'.  According 
to ONCRPC when a client handle is created with one of the clnt..._create() 
functions, the credential fields are NULL, signifying no credentials or 
verification to be performed at the server.  However, it appears that with 
glibc-2.2.4-13 this is not with the client but private to a thread which is 
good if you want to have different threads have different credentials.  
However, I still think that all threads should first get "a default" and then 
be able to change this default as needed.

Comment 3 Need Real Name 2002-05-08 16:22:34 UTC
We have been bitten by this bug as well.  The required workaround places a
serious bookkeeping burden on multi-threaded clients.

This excerpt from Sun's online documentation gives a good indication of the
correct semantics:

In a multithread client program, a thread can be created to issue each RPC
request. When multiple threads share the same client handle, only one thread at
a time will be able to make an RPC request. All other threads will wait until
the outstanding request is complete. On the other hand, when multiple threads
make RPC requests using different client handles, the requests are carried     
out concurrently. Figure 4-1 illustrates a possible timing of a multithreaded
client implementation consisting of two client threads using different client

Thanks - rk@spinnakernet.com

Comment 4 Mike McLean 2003-01-02 18:46:28 UTC
This bug has been inappropriately marked MODIFIED. Please review the bug life
cycle information at 

Changing bug status to ASSIGNED.

Comment 5 Ulrich Drepper 2003-04-24 00:06:42 UTC
This is how RPC in multi-threaded apps is designed to work now.  Before the
change (before RHL7.2) RPC better never was used in multi-threaded apps.  It
couldn't work reliable.  Now the RPC state is thread local which brings with it
its own set of limitations but it's better than nothing.

Comment 6 Mark Tsombakos 2004-05-13 15:35:47 UTC
Yet on 04-22, you said,

On Thu, 2002-04-11 at 15:12, Zack Weinberg wrote:
> sunrpc/auth_none.c contains static private data, which is initialized
> once per calling thread by authnone_create().  authnone_marshal
> accesses this data by the per-thread data pointer.

I've applied the patch now.  It indeed seems to be consistent with
Solaris does.  Thanks,


I was also bitten by this bug, but applied the patch from RedHat 9,
and the problem is fixed.

Note You need to log in before you can comment on or make changes to this bug.