[2249] in Kerberos_V5_Development
Re: Problems with the current com_err routines...
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed Feb 19 17:57:50 1997
Date: Wed, 19 Feb 1997 17:57:13 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ken Raeburn <raeburn@cygnus.com>
Cc: probe@lehman.com, krbdev@MIT.EDU
In-Reply-To: Ken Raeburn's message of 19 Feb 1997 17:25:51 -0500,
<tx1raicigb4.fsf@cygnus.com>
From: Ken Raeburn <raeburn@cygnus.com>
Date: 19 Feb 1997 17:25:51 -0500
Actually, aside from namespace issues, I think Richard's solution
sounds reasonable. (I haven't looked at the code, just the email
comments.) The _et_list form can never be thread-safe. With most
platforms moving towards having thread support these days, this is a
problem. A change needs to be made, and it can't be 100% compatible.
Richard's code is just as non-thread safe. If you want to be thread
safe, you need to either (a) do the et_ctx structure, which I experimented
with, which forces everyone to carry the et_ctx arround, or (b) arrange
to call locking primitives somehow. I'm actually starting to think that
registering locking primitives is going to make the most amount of
sense.
> This should allow Unix krb5 library to continue to work without
> requiring any changes in the com_err library, while allowing the Windows
> side to use the new dynamic registration and de-registration of the
> com_err library.
>
> Comments?
Two words: dlopen, dlclose. If these are used with a library using
com_err and registering error tables, the same problem will arise, on
UNIX. Not very common, but I'll probably be looking into using dlopen
for Kerberos code in the not-too-distant future, actually. (I don't
know about dlclose; that code isn't mine, I'm just looking for the
best way to hook Kerberos in.)
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.
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.
- Ted
