[17009] in Kerberos_V5_Development
Re: RFC: libverto nearing release
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jul 7 18:15:30 2011
MIME-Version: 1.0
In-Reply-To: <4E15F9F4.40303@redhat.com>
Date: Thu, 7 Jul 2011 17:15:26 -0500
Message-ID: <CAK3OfOjd2fe_A5u7cXaA9-pQdkhbcF-D=sT20h6-LKvwhXCsag@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: dpal@redhat.com
Cc: 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 1:24 PM, Dmitri Pal <dpal@redhat.com> wrote:> On 07/07/2011 11:43 AM, Nico Williams wrote:>>> 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.>> You can never be sure about those who "must" do something "would"> actually do what they "must".> Adding safeguards is a prudent approach.
Let's drop this sub-thread. I've convinced myself that it will bepossible to use libverto safely, though with much care to ensure thatlibverto is *only* used in new interfaces, which implies that asyncinterfaces need to be implemented up and down the stack in the case oflayered software (think of libldap using sasl/gss where libgss and/ormechanisms want to use libverto). Or one must accept the subtleincompatibility implied by using libverto in existing interfaces --Nathaniel commits to fixing libverto if such a case arises anyways.
On the whole, it's not a bad idea to at least try to get everyone touse signals through a single library.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
