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
