RFC: libverto nearing release

[Nathaniel McCallum]

On Thu, 2011-07-07 at 10:43 -0500, Nico Williams wrote:
> On Thu, Jul 7, 2011 at 10:12 AM, Nathaniel McCallum
> <npmccallum at redhat.com> wrote:
> > On Thu, 2011-07-07 at 10:04 -0500, Nico Williams wrote:
> >> 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.
> 
> Why not?  The module should know which handlers it's installed.

Incorrect.  The signal handlers are registered internally to the library
in question (glib, libev, etc).  That is the choice to register or
unregister signal handlers is a layer below the libverto module for a
given library. I could make some assumptions about this, but dladdr() is
cleaner.

> Why not?  It's just something modules must do.  To be portable signal
> handlers must only have global state, so you make sure that the
> associated global state is sane at all times.  Hardly problematic.

Maybe.  But if I make that assumption, and some event loop does
something wonky, than I get to keep the pieces. Again, dladdr() is
cleaner.

> > 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 ).
> 
> I don't think that's good enough, though if you make some assumptions
> it might work *today*, but who knows when your assumptions might
> break.

In the worst case scenario, the protection currently implemented will
fail to protect the user. I clearly warn the user of this in the
documentation for the verto_add_signal(). What is the problem?

> > 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.
> 
> I think you should worry about Windows.  Also, dladdr() is present in
> Linux and Solaris, so it's really the BSDs you should worry about.

libverto is already working on NetBSD and OpenBSD.  FreeBSD will
probably work, but I'm having some dependency issues.  I don't have a
copy of Solaris (hopefully, Greg is working on this) or Windows (I am
working on this).  There is already a win32 port that was mostly
copy/pasted from existing *working* code in another project. It remains
untested on win32 until I can get Windows running.

In short, this "problem" (which doesn't actually exist) has been talked
to death for no reason. My solution is clean, works everywhere and
provides at least some basic crash protection. The related functions are
clearly documented as to their restrictions. This is about the best we
can get on anything.

Nathaniel