[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: compiling back-perl with perl 5.8.0

Matthew J Backes wrote:
[...]


I'm not clear about the limits of the multiplicity system; is it
possible to give each thread it's own instance of an interpreter?

You can have multiple interpreters per thread even. PERL_SET_CONTEXT is called whenever a different interpreter is to be used. The idea is that each interpreter instance has a variable. 'my_perl' is the 'implicit context' or default instance, IIRC.

Does a call to PERL_SET_CONTEXT affect other threads or interpreters,
or is it entirely thread-local, provided no other threads mess with
the interpreter(s) involved?


It's always protected by the mutex in OL, I believe it's threadsafe. It's in the perlembed POD. This function ( or macro ) sets up the interpreter to be used. At least on Win32, if this is not called then the first use of a perl embed function in a non-inializing thread would result in a crash. Therefore 'PERL_SET_CONTEXT' has to be called at every potential thread entry point, eg. in at the top of do_add(), do_search(), etc...

perlembed indicates building perl with -Dusethreads and -Duseithreads
may be more appropriate for this arrangement.

I'm somewhat confused about HAVE_WIN32_ASPERL... it looks like what
I'd expect from an autoconf system checking for options in perl -V,
but if I run find -type f |xargs grep ASPERL on the openldap tree, the
only usage of it seems to be the #ifdefs in
servers/slapd/back-perl/...

Was it part of the autoconf tests at one point, and should it be
again?



No it's not part of the autconf. You can add it has part but that would only benefit cygwin users who use activestate perl, a strange combination. The macro should be defined in the windows config file 'portable.nt', which still has to be edited by hand unfortunately.

Do a 'perl -V' and check what defines perl was built with. 


  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT


Yup. That's why you have the issues. A quick work around would be to have a separate installation of perl that does not define MULTIPLICITY, and build against that. But the problem should still be fixed.



#ifdef HAVE_WIN32_ASPERL /* pTHX is needed often now */
# define PERL_INTERPRETER my_perl

...

Looks like the backend wants to call the interpreter different things
for different versions.  If we make the same changes for checking
MULTIPLICITY this should work fine.



'my_perl' is the default perl interpreter variable name in perl versions >5.6 with MULTIPLICITY. All the perl embed macros that don't expect a interpreter value use 'my_perl' as the interpreter. Not using it would mean a break from the <5.6 way of doing things, and we would have to always defined a interpreter variable and pass the name around.

Thank you, I'll see what I can do. 


Good luck.

Matthew Backes
lucca@csun.edu


--Kervin