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

Re: compiling back-perl with perl 5.8.0

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

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

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



> 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

/* 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