[Date Prev][Date Next]
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(),
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
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.
/* 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.