[Date Prev][Date Next]
Re: commit: ldap/servers/slapd/back-perl SampleLDAP.pm
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".
> 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.
> 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