Asynchronous operation and krb5 dependencies

[Simo Sorce]

On Fri, 2011-06-03 at 11:59 -0500, Nico Williams wrote:
> On Fri, Jun 3, 2011 at 11:01 AM, Greg Hudson <ghudson at 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 same
> libevent API -- that's my point.  Why invent yet another async I/O API
> just because you feel the need to write a wrapper around multiple
> distinct 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 with
> different names and different symbl naming even when they serve much
> the same purposes.

It's not a dll-hell problem, each library would be perfectly loadable in
the same binary.

You just want to use the same event loop for all the code.

And because there are multiple event loops available the best way to do
that is to make the eventloop component loadable.

Because each event loop library has a slightly different interface you
then also need a wrapper so that it looks identical to the libkrb5 code.

> That's one answer to DLL hell; there are others.  But at least now
> we've stated that DLL hell is the real problem.  Or I've stated that
> -- maybe you could confirm it :)

I deny it is. There is actually really no linking issue at all, it is a
'what I want to use today issue'.

Statically linking all these libraries together would make absolutely no
difference, you would still need a way to select which event loop to use
for all components, and you do not want to build the same wrappers for
each library that has this issue.

> Other answers to DLL hell include:
> 
>  - thin wrappers should be statically linked (why not?

Because it means rebuilding every time you want to use a new event loop
as oppose to passing in a vtable from the application.

>   being thin the
> code duplication involved is too small to care about, and as for
> patching, being thin also means a lower likelihood that you'll need to
> patch the wrapper library);
> 
>  - RTLD_GROUP (on platforms where it is available);

Irrelevant, there are no symbols issue to care about.

>  - static linking of all DLL hellish things, not just wrappers (for
> example, the SQLite3 community insists on static linking of
> libsqlite3; when I was at Sun/Oracle I objected to that approach, but
> towards the end I softened my stance);

This is not the same class of problems libverto is being proposed for.

If you are saying: statically link libkrb5 into every application then
I'll look at you as a Martian :-)

The reason is simple: I am not going to rebuild hundreds of applications
every time a security bug is found in libkrb5 :-)
(and my customers are not going to download hundreds of megabytes for a
change that involves a few kilobytes)

>  - something else?

Perhaps :-)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York