RFC: libverto nearing release

[Nathaniel McCallum]

On Thu, 2011-07-07 at 10:04 -0500, Nico Williams wrote:
> On Wed, Jul 6, 2011 at 6:26 PM, Nathaniel McCallum
> <npmccallum at redhat.com> wrote:
> > 3. It is not dlsym() I'm worried about, but dladdr(). I'm honestly not
> > sure if there is a win32 equivalent for this. libverto uses dladdr() for
> > two purposes. The first is to get the file name of the libverto library.
> > I'm extremely confident we can do this in win32. The second is to test a
> > signal handler on win32 to determine if it is in unmapped space. I have
> > no idea what we will do here on win32, but we might be able to do
> > something similar.
> 
> The first use of dladdr() is so you can format a path of a shared
> object to load for a specific libverto module.  I think there are
> various ways of handling this instead of depending on dladdr().  For
> example, if the caller gave you the path to libverto they used to
> dlopen() it, you're done.  Or if libverto is linked in instead of
> dlopen()ed, then you'd open the modules by relative path and let the
> system find them using whatever search path is in force.

I agree, there is other stuff I can do here.

> The second use of dladdr() is completely superfluous: you're checking
> for invalid signal handlers after dlclose()ing a module.  There's
> three options for that: a) require that modules clean up signal
> handlers in .fini, b) tear down all event handling for that module
> such that there ought to be no signal handlers left, then dlclose()
> it, c), don't dlclose() the modules.

This one is not so trivial.
a) won't work. the module doesn't know which handlers "belong" to it and
it can't reset handlers for other modules.
b) same problem as a).
c) this *might* work, but it assumes that the handlers are in a sane
state, an assumption I'm not willing to make.

I think the approach I've chosen here is the best one, and I think there
is a way to do this on win32 ( see
http://msdn.microsoft.com/en-us/library/aa366902(v=vs.85).aspx ).

In short, I'm not super worried about a win32 port. At best, I think it
will change some of the internal semantics. I'm mostly focused now on
getting it to build/work on non-linux.

Nathaniel