Re: compiling back-perl with perl 5.8.0

[Matthew J Backes <lucca@csun.edu>]

On Mon, 04 Nov 2002 14:44:54 -0500
"Kervin L. Pierre" <kervin@blueprint-tech.com> wrote:

> I can't remember the details right now, but how we build back-perl
> depends on how perl itself was built.  The needed change is due to
> the change in the perl embed api between versions 5.6 and 5.6.1, I
> believe.

> Currently, If perl is built with MULTIPLICITY ( which allows more
> than one interpreter to run ) then OpenLDAP could crash on the first
> use of the interpreter in a thread that did not create it.  Thats
> because PERL_SET_CONTEXT macro has to be called with the interpreter
> needed.

> The new MULTIPLICITY flag is where most of the change occurs, and to
> be more precise, some of the changes protected by HAVE_WIN32_ASPERL
> should be protected under HAVE_PERL_MULTIPLICITY which should be set
> at config time using 'perl -V' autoconf type test to figure out if
> it is needed.

Currently all threads seem to reference the same perl interpreter,
protected by a mutex.

So we the accessing-interpreter-from-the-wrong-thread problem can be
fixed by PERL_SET_CONTEXT wrapped in a test for multiplicity, yes?
Probably just inside the mutex.

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?
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?

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?

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

  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT

Hm.

> The 'my_perl' errors are due to the new naming of the implicit perl
> interpreter variable, I believe.  It use to be called something
> else.  Another perl define that may need to be looked at is
> IMPLICIT_CONTEXT

#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.

> I'd be happy to help anyone who's interested in making the updates.

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

Matthew Backes
lucca@csun.edu