mechglue registration of gss_buffer_t pointers
Nicolas.Williams at sun.com
Tue Oct 23 10:52:21 EDT 2007
On Tue, Oct 23, 2007 at 09:29:08AM -0400, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> writes:
> What can we do to figure out how well we could do with a registration
> mechanism and what performance is required?
Any registration mechanism would have to be thread-safe and not
materially slower than an MT-hot malloc()/free(). Alternatively any
registration mechanism needs to be build-time optional so we can someday
do code drops and still opt out of it.
You could try something like this:
Use spin-locks and thread-specific data to register allocations on a
per-thread basis. Let the first allocation in any thread and
releasing buffers allocated in other threads be the only potentially
But that seems a lot more complicated to me than playing linker games
> Nicolas> There are several things we could do. Here's two:
> Nicolas> - Play linker games to ensure there's a single
> Nicolas> gss_allocator for the mechglue and all mechs
> One problem with this is that it makes it difficult to use
> language-specific allocation mechanisms. You'd like to be able to use
> new in C++ or the corresponding Objective C mechanisms if you write a
> mech in those languages.
C++ and Objective C can call external C functions, which covers that.
Besides, they need to let you expose a C call interface, else you can't
write any mechanism in those languages for a mechglue with C calling
What other languages did you have in mind that can export C functions
but cannot call external C functions? Or do you plan a mechglue that
can support SPIs for multiple languages' calling conventions?!
The other alternative I mentioned earlier would also work with any mech
that exports a C-based SPI.
Right now I just don't buy this argument that playing linker games would
prevent development of mechanisms in other languages.
I expected a different argument against having a single mechglue-
Is there a list of requirements and constraints that will apply to any
solution here? I can't really help if every solution I offer is met
with some previously unmentioned constraint. Or have you committed
simply yourself to a solution already?
More information about the krbdev