On Mon, Dec 17, 2007 at 10:22:09PM -0500, Jeff Squyres <[EMAIL PROTECTED]>
wrote:
> Having now RTFM'ed, I still have a few of my original questions, but
Sure, out with them, you are certainly welcome here. It is just nice and
proper to try reading the docs first, but I hope you value the fact that I
did answer all your questions, whcih cosst considerable time :)
> 1. My bias/assumed definition for "embedding" was to a) include the
> entire libev tarball in Open MPI (via Subversion's 3rd party/vendor
> import conventions),
That is certainly possible, you don't *have* to run the configure script
and even if, --disable-shared owuld do just as nicely.
> b) have our configure call your m4 macros, and
Certainly possible as documented and practised by both gvpe and urxvt.
> c) have an upper-level Makefile.am traverse into the libev directory and
> use your Makefile.am.
Since there is only a single .c file for the libev core, that sound slike
overkill, and I think its the wrong approach when embedding. It is suualyl
vastly easier to just provide an #include and a single .c file elsewhere, or
write your own Makefile.am.
> It was from this context that I was asking about renaming the library to
> lib<foo>ev.la and/or not installing it.
Thats up to you, you certainly can.
> 1a. You seem to indicate that you only want the *source* to be
> embedded, but not the distributed Makefile.am. However, your docs say:
>
> "The goal is to enable you to just copy the neecssary files into your
> source directory without having to change even a single line in them,
> so you can easily upgrade by simply copying (or having a checked-out
> copy of libev somewhere in your source tree)."
That is certainly the case, and is how other projects handle it. It works
fine.
> In this case, having an expanded tarball in our tree is "close enough"
> to having a checked-out copy of libev. As such, it would be desirable
> to just be able to descend into the libev directory via a SUBDIRS
> entry in an upper-level Makefile.am and use your Makefile.am without
> modification.
I will not support that specifically, the added effort is just not worth
anything: it complciates the makefile a lot, requires embedding users
to learn a lot about how to use it and has no technical advantages
whatsoever.
> noinst is preferable for the reasons you already cited (I would prefer
> not to install it, but rather include/embed it in our own library --
> this is what we do with libevent today).
Thats what you should do with libev. Just have a look at the existing
projects that do that, they all simply provide a small configuration
wrapper and then include the necessary files.
They actually provide a header file and an implementation file, for
example, urxvt sources simply #include "ev_cpp.h" and compile ev_cpp.C
(thats used as an example in the documentation).
The EV perl module directly includes the ev.c file and installs a wrapper
around the installed ev.h file (the latter is installed in a private
directory) called "EV/EVAPI.h".
> 1b. Along the same lines, if we don't want to modify the libev source
> at all, we can't supply all the #define's to rename the public symbols
> without additional source wrappers.
Thats what I recommend. libev was specifically designed for a wide variety of
config options without having to patch the source, youc na just copy the
relevant files, as stated in the documentation.
If your case would need more configuration or flexibility (unlikely, but
certainly possible, as every embedding case is a bit different), I'd be happy
to provide extra config options. Not having to patch the sources is the
utmost goal here, to provide easy upgrades and maintainability.
(Although distribution maintaienrs will argue that having a non-embedded
libev shared lib will make this even easier as you only have to recompile
that lib in case of security issues etc., but the library is small
enough to make embeddign a very viable options especialyl for standalone
programs).
> I agree that #defines are cheap
> and the right way to go, but if we're literally just compiling your
> source (such as via an expanded libev tarball or a libev checkout in
> our tree), we'd either have to provide additional libev source
> wrappers or modify your source to insert those #define's (and keep up
> with them as the libev API grows/changes).
Well, you have to :) There is no other way possible except through a
wrapper or patching, thats how C works (ok, you can also provide lots of
-D switches to the compiler too, but I consider a wrapper better).
Apart from those solutions, there simply is no other way, as you you
somehow have to tell libev where to find its header files, which watcxhers
are to be enabled, wether to use autoconf or not etc.
If you want to solve it in a different way you will likely find that you
cannot: Either you embed, or you lose the configurability.
> It would be preferable to keep the libev/ directory be 100% libev source
> and not have to provide any source wrappers.
You can keep it 100% libev source and still provide a source wrapper.
libev has been designed to work like this, it is used like this in
existing embedder apps, and I don't see any other way of providing
configuration options to libev.
> In summary, the following two changes would be most helpful:
>
> - an m4 macro to change the output library to be noinst
You can already do that easily using the documented interface in your own
interface.
> - an m4 macro to change (prefix?) all the public symbols in the output
> library
Already possible, as you can easily do that yourself, too, even
programmatically.
> Are these changes possible?
They are not needed, it cna all be done with the existing sources.
I really wonder if you really read the documentation, which explains that,
or have looked at existing applications. If you don't know how, I can
recommend way of doing the wrapper macros, wether it is actually required
or not.
> that wants to embed libev: they allow us to safely link in the
> generated libev library to our library, and keep the libev/ library
> completely "pure" -- no modifications and no source wrappers.
While that might be true, there are simpler and easier ways to achieve
that. You apperetly want with your head through the wall, but that is not
advisable nor really useful. A simple wrapper will give you a lot more
flexibility and future-proofness, is easier to program and use, and easier
to maintain for all sides.
> This will definitely help maintenance over time.
I doubt it.
> Or are these changes contrary to your definition / philosophy of
> embedding?
No, they aren't, but I question your conjecture of making it easier to
maintain, as I think the opposite is true, and they are certainly not
neecssary to achieve all your goals: Simpler methods are available to
solve your problems.
> 2. Static: per the note above (being distracted while typing technical
> e-mails), I wasn't clear what I meant - sorry. What I meant was that
> libev's *public* symbols are not static.
Right, I didn't understand that you wanted to repeat the obvious, though,
so I interpreted your statement as being meaningful in some way.
> *can* be symbol conflicts between an embedded libev and a non-embedded
> one. The gcc example I gave was also borked; what I meant was:
>
> gcc my_app.c -lmpi -lev -o my_app
>
> In this example, without #define's to rename all the public symbols in
> libmpi, my_app.c will get the system-installed ev.h (that matches the
> API in -lev)
> but will actually link against the ev symbols in libmpi
> due to linker left-to-right resolution.
Note that renaming won't help you in that case, you would still get the
wrong header file. You need to solve this, too, e.g. by renaming your copy
of ev.h (which is certainly possible without patching with the current
sources).
But renaming is certainly possible with the current approach without
patching the sources, if there is a need for additional complexity I would
like to hear about it.
If you convince me that this is an unreasonable burden for openmpi, I
can consider writing a wrapper macro that allows renaming. But you need
arguemnts for that, and I haven't heard any (you gave arguments on why
renaming might be useful, and while I not agree with all of them, one
sound argument is enough, and I am fully ok with openmpi requiring renamed
symbols. I just think its already easily possible. If you think otherwise,
you need to give arguments).
> This is why I was asking for built-in support for renaming the public
> symbols (e.g., via an m4 macro to trigger a bunch of #define's -- I
> gave a ./configure example without any context or explanation).
Well, I think its trivial to do that in the context of mpi - each embedder
has such demands, and its easy to do that without requiring extra autoconf
support.
> 2a. However, you made a comment in one of your replies that I didn't
> fully understand:
>
> What do you mean that there can only be one event loop in a process /
> an event loop needs to "take control" of the process? What does "take
> control" mean?
It means that if you are in e.g. ev_loop, than the Tk/Qt/whatever event loop
will not run at the same time, so ev_loop takes control of the thread, you
can't run two loops at the same time in the same thread.
If two libraries, or an application and a library, both use libev,
then the preferable approach is to make them use the same libev, as
then everybody will be happy. For example, the EV::ADNS, EV::Glib and
Net::SNMP::EV modules all only register watchers for EV, so when the main
program runs ev_loop, everything will work in an event-based way.
In general, its bad if a library blocks even though internally it is
event-based. There are good reasons for that, for example, convinience
functions when the main program doesn't care about events (a blocking
API), or the fact that the event library is too obscure to be installed
seperately (it adds burden!).
So embedding the event loop while hiding it usually takes features away
from the library user and makes integration difficult.
> If all the symbols are separate (e.g., via #define's),
> his there a reason that two libev's can't co-exist in the same process?
Only because when one event loop runs, the other doesn't. A typcial
example of a process-wide resource are signals: you cannot have two
libev's coexist in the same process using signals or child watchers, it just
won't work. The same is true for fork and other global things.
If openmpi doesn't require any of those, and doesn't require coexistance with
other event loops in the same program/thread, then embedding is a very viable
option.
For example, gvpe supports no plug-ins, extensions etc. and, as a
standalone program, so ideally suited for embedding.
rxvt-unicode supports perl extensions, and those often are event-based. It
would be nice if those perl extensiosn could use event-based modules.
rxvt-unicode gets around it by supporting AnyEvent, so modules using it will
automatically work, but for that, urxvt has to provide its own perl intefrcae
to its own embedded libev. This is an historic thing, and also stems from the
fact that it can be compiled without perl, in which case it needs its own
event library. In this case, embedding is a necessary evil.
The EV perl module embeds libev, too. It provides its own C API. While
this adds compelxity and rules out other uses of libev, it will not suffer
form the link problem because its .so file is not visible in the extension
namespace. It was done because it was much easier, and its easier for the
user not to have to download a separate libev and install it. In this
case, using a separate shared libev is much preferable, but it wasn't done
for ease of integration.
openmpi would be near the EV case (both "extension libraries") or maybe near
rxvt-unicode. there might be valid reasons to hide ev, but it also has
disadvantages.
In any case, hiding is fully supported.
> My goal would be that the libev embedded in Open MPI would be 100%
> private -- what we do in our event loop should not affect what the
> application does with its event loop (and vice versa, obviously).
And I fully support that goal and think that, except for minor as-of-yet
unknown problems, this is already easily possible.
> Hopefully, this is much more clear than my original posts...
Very!
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
