RFC: libverto nearing release

[Nico Williams]

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.

The bigger problem is when the application (or worse, other libraries)
also install signal handlers and stack them (by saving the previous
handler).  There's no fixing that, except via (c), or via
documentation.

> b) same problem as a).

Same answer.

> c) this *might* work, but it assumes that the handlers are in a sane
> state, an assumption I'm not willing to make.

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.

> 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 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.

Nico
--