[2254] in Kerberos_V5_Development
Re: Problems with the current com_err routines...
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Thu Feb 20 05:06:01 1997
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: probe@lehman.com, krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 20 Feb 1997 05:05:08 -0500
In-Reply-To: "Theodore Y. Ts'o"'s message of Wed, 19 Feb 1997 17:57:13 -0500
"Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> Richard's code is just as non-thread safe.
But, depending on the approach used, it could be *made* thread-safe
without again changing the interface between library and error
tables. Actually implementing that can be left for the future; the
Windows DLL problems are more immediate.
> Not necessarily; dlopen() and dlcose() don't necessarily presuppose
> sharing across different processes. In fact, usually dlopen() gives
> each process its own private copy of the shared library's static
> variables. Hence, we don't need to do anything special with dlopen() at
> all.
It's dlclose that's the issue. The implementation is allowed to toss
away the address ranges previously used by the library. That puts you
in the same situation Windows does.
> Note that the SAP R/3 application server is already using dlopen() to
> gain access to the GSSAPI library, and it works just fine on both OSF/1
> and Solaris.
But does it ever call dlclose? Even if it does, the specs I've seen
said that dlclose is *allowed* to throw the library away; that a given
implementation might not doesn't make the code correct.
