[16984] in Kerberos_V5_Development
Re: RFC: libverto nearing release
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jul 7 11:43:25 2011
MIME-Version: 1.0
In-Reply-To: <1310051558.16598.5.camel@localhost>
Date: Thu, 7 Jul 2011 10:43:21 -0500
Message-ID: <CAK3OfOjPwUpDzC08nVfgeZpJVEvVTKCkxL0tEnRno8JAUyo4JA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, Jul 7, 2011 at 10:12 AM, Nathaniel McCallum<npmccallum@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 previoushandler). There's no fixing that, except via (c), or viadocumentation.
> 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 signalhandlers must only have global state, so you make sure that theassociated 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 assumptionsit might work *today*, but who knows when your assumptions mightbreak.
> 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 inLinux and Solaris, so it's really the BSDs you should worry about.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
