mechglue registration of gss_buffer_t pointers

[Nicolas Williams]

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

But that seems a lot more complicated to me than playing linker games
(see below).

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

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

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?

Nico
--