Bug 62969
| Summary: | Can not share RPC client handle between threads | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <lesliek> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.2 | CC: | fweimer, lesliek, rk |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-04-24 00:06:42 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Need Real Name
2002-04-08 17:33:55 UTC
Why do you think it is a bug? RPC is not shared between threads, each one has its own. 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. 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 handles. ------ Thanks - rk This bug has been inappropriately marked MODIFIED. Please review the bug life cycle information at http://bugzilla.redhat.com/bugzilla/bug_status.cgi Changing bug status to ASSIGNED. 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. 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, http://sources.redhat.com/ml/libc-alpha/2002-04/msg00167.html I was also bitten by this bug, but applied the patch from RedHat 9, and the problem is fixed. |