[16835] in Kerberos_V5_Development
Re: Asynchronous operation and krb5 dependencies
daemon@ATHENA.MIT.EDU (Nico Williams)
Fri Jun 3 12:59:52 2011
MIME-Version: 1.0
In-Reply-To: <1307116872.2281.28.camel@t410>
Date: Fri, 3 Jun 2011 11:59:47 -0500
Message-ID: <BANLkTi=zqjacor8n-A0McNFeVV6VdZNLjg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Fri, Jun 3, 2011 at 11:01 AM, Greg Hudson <ghudson@mit.edu> wrote:> On Fri, 2011-06-03 at 11:31 -0400, Nico Williams wrote:>> I don't get the need for a wrapper library for async I/O -- libevent>> is such a library, and one can easily implement libevent-compatible>> wrappers around alternative event loops. Or was that what you were>> proposing?>> libevent is not, to my knowledge, an event loop wrapper library; it's an> event loop implementation with a number of internal back ends for event> signalling. You can't tell libevent to forward operations (like adding> a read callback for a socket) to g_main_* or libdispatch or whatever.
Libevent is not a wrapper. But you can make a wrapper with the samelibevent API -- that's my point. Why invent yet another async I/O APIjust because you feel the need to write a wrapper around multipledistinct event loops?
> Someone could write an libevent-ABI-compatible wrapper around g_main_*;> a number of libraries have done so. But that's not enough. Imagine> yourself in the role of operating system distributor, trying to package> all of the following components:
OK, so you get what I meant :)
> libevent> krb5> an application using g_main_* and krb5> an application using libevent and krb5> an application using libdispatch and krb5>> How do you get every application to use the (hypothetical, future)> asynchronous libkrb5 APIs such that they each register their callbacks> with the correct event loop? That's what libverto is for.
You're saying that the answer to DLL hell is to have libraries withdifferent names and different symbl naming even when they serve muchthe same purposes.
That's one answer to DLL hell; there are others. But at least nowwe've stated that DLL hell is the real problem. Or I've stated that-- maybe you could confirm it :)
Other answers to DLL hell include:
- thin wrappers should be statically linked (why not? being thin thecode duplication involved is too small to care about, and as forpatching, being thin also means a lower likelihood that you'll need topatch the wrapper library);
- RTLD_GROUP (on platforms where it is available);
- static linking of all DLL hellish things, not just wrappers (forexample, the SQLite3 community insists on static linking oflibsqlite3; when I was at Sun/Oracle I objected to that approach, buttowards the end I softened my stance);
- something else?
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
