Re: commit: ldap/servers/slapd/back-perl SampleLDAP.pm

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Dagobert Michelsen writes:
> Am 19.06.2007 um 17:22 schrieb Hallvard B Furuseth:
>> Is there a max number of Perl interpreters per backend?
>
> I suppose you mean "per database".

Right.

> There is exactly one interpreter in use for each active connection
> and each configured back-perl database because allocation is done
> on connection_init.

Hmm.  That sounds like adding a perl database can have a noticeable
impact on performance (and memory use?) even if it is rarely queried.
In particular if it calls a user-defined connection_init Perl method.
Ought to test and see, I guess...

> (...)
> The disadvange is that there is no data sharing between connections.
> Implementing data sharing with this model is quite complex and
> involves attaching (Perl-)magic to shared variables which implements
> mutex'ed access between interpreters.

Perl has "use threads::shared", but maybe that only works for threads
created by Perl.

>>> - argument passing is done in a style similar to Net::LDAP,
>>>    parsing is no longer needed as attributes and values are
>>>    separately stored
>>
>> You might not even need to do that.  Could wrap an Entry in a class
>> which translates slapd attributes to Perl lists on demand.
>
> This is possible, however not trivial: The C data structures
> would be implemented as blessed scalars containing the C pointer.
> Access method could then convert the data on demand.

Yes...

> However,
> the C pointer must be some kind of "weak" pointer which is
> only valid in the context of this method invocation.  Otherwise
> the scalar with the C reference could be stored in the interpreter
> and deferenced later in another method entry where the C data
> has already been freed.

Yes.  A number of slapd stuctures have a .<something>_private member
which can be used for this, and there are also some callback methods to
clean up.  Overlays can make this rather hairy though, I still haven't
gotten around to learn how that works.  Together, I think these can be
used to implement the "weak" pointers.  I have not tried that myself
though.  And if it can be done later there is no hurry to do it now.

> As the method usually does something with the parameters the data
> is needed anyway, so savings here should be minimal if not negative.

Depends on the API and which data we are talking about, I guess.
As you say:

> Another thing is access to seldom used data like connection
> parameters or operation details where transformation to your
> proposed structure would indeed be useful.


>>> - switching to old-backend-compatible-mode is done when
>>>    no connection_init method is found
>>
>> That sounds like a hack, one might not be interested in defining a
>> connection_init method anyway.
>
> In my current implementation it is mandatory to implement
> connection_init. The returned value must be a reference to
> an object on which the methods for the operations are called
> (like search, compare, etc.)
>
> If you have a usecase for an application without connection_init
> I would like to hear it.

Well, only a few backends and overlays set it, so there are many
use cases for not having the C variant.  Obviously there are none
when it's used for setup like you describe.

Possibly you could eliminate the need for it by using a blessed
connection type instead, and assign a perl interpreter to a connection
only at the first operation which has need for one.  Easy to say when I
haven't seen the code, of course...

>> I also suggest you do not let compatibility get in the way of good
>> design decisions for the new code.  If good design leads to bad
>> compatibility, we could always put the old back-perl in
>> contrib/back-oldperl or something.
>
> Including the old backend is something I really would like to
> avoid as this means adapting autoconf-stuff and be confusing.

OpenLDAP's configure doesn't touch contrib - so it becomes the user's
problem instead...  But yes, it would indeed be nice to avoid that.

>> Or the user has made updates in Perl structures which are not
>> reflected in the C structures they came from.  I looked into doing
>> this with Python once, but punted since the Python C API #includes a
>> header with Python autoconf variables which conflict with slapd's
>> autoconf variables.
>
> Do you have some design notes of this left which you can send me?

Not really, but I'll see if I can dig something up.  Too large a portion
of the "design" part consisted of getting around the conflicting
autoconf.

-- 
Regards,
Hallvard