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

Re: [dev_ldap] RE: back-perl and password/user synchronization

Hi,

Howard Chu wrote:
back-perl doesn't use perl's thread support, it uses a mutex to serialize
all access to the perl interpreter.

The problem is that threads do not seem to get access to that single interpreter. I can access the interpreter fine from the thread that calls the initialization functions from servers/slapd/back-perl/init.c, but any calls from the spawn threads, ie the ones spawn to answer a query, result in various assorted memory violations. It's not just a scope issue, the thread can see the extern perl_interpreter ( or my_perl as it's called in 5.6 ) pointer. I'm guessing that perl libs use the stack somehow in intialization.

The only way around that, I believe, is to build your perl libs with backward compitable threading support, like Luke did.

Therefore you only need one instance of
the interpreter, and you don't need a threaded perl library.

yeah, but that'll get real ugly, real fast :) I don't think every thread starts a new interpreter in ernest, but it goes through the motions. I am trying to get some of these things clarified.

I think you're
beginning to see the nightmare I was referring to.

funny thing, after a few hours of chasing stack violations one night, I remembered that :)

It sure would have been
nice if someone
had spent some time designing it...


Yes it would have.  But fixing it would be the next best thing.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support


-----Original Message-----
From: owner-openldap-devel@OpenLDAP.org
[mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kervin Pierre
Sent: Wednesday, March 20, 2002 7:30 PM
To: lukeh@PADL.COM
Cc: dev_ldap@myinternet.com.au; openldap-devel@OpenLDAP.org
Subject: Re: [dev_ldap] RE: back-perl and password/user synchronization


Hi,

When do you see that happening ( ITS entry)?  If you can send me the
changed files without review?  I've been fighting this for the last few
days now, and I think the code is winning :)

I love to see how you got it working.  I am beginning to realize that
Perl 5.6 thread module is very different from the old api, worse still
I'm building on win32.  New threads can't just use the extern
PerlInterpreter pointer, they have to use PERL_GET_CONTEXT and
PERL_SET_CONTEXT etc.  I'm still trying to figure these things out. I
found an email at
http://lists.zope.org/pipermail/zope-perl/2000-June/000028.html
explaining this.  So it seems to me that a new perl interpreter has to
be allocated for each thread.  I tried this and it at least got rid of
some of the issues that I had, but I'm still working on others.  This
seems to have to do with how your perl libraries were built.  The
MULTIPLICITY, PERL_IMPLICIT_CONTEXT, and PERL_IMPLICIT_SYS defines
affect this.

PS.  How does a ldap bind work with back-perl?  There is no bind perl
function in SampleLDAP.pm, do I have write one?

--Kervin



Luke Howard wrote:

I think you just lucked out. Perl internals are a nightmare, 

with different

data structures defined depending on whether you configured for 

embedded,

threaded, or standalone, and some combinations of the above. My general 


OK, we got it built and working with Perl 5.6. We only changed the
search API to pass the search base, alias dereferencing policy, and
scope to the Perl module, as well as allowing modules to return
actual LDAP result codes via the frontend.

We'll submit an ITS when we have reviewed the changes.

cheers,

-- Luke

--
Luke Howard | lukehoward.com
PADL Software | www.padl.com




--
http://linuxquestions.org/ - Ask linux questions, give linux help.
http://splint.org/ - Write safe C code. splint source-code analyzer.







--
http://linuxquestions.org/ - Ask linux questions, give linux help.
http://splint.org/ - Write safe C code. splint source-code analyzer.