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.