Hello
I was a little afraid by the advertisement I found
Thread-lock:
Basically calls into the LDAP lib are serialized by the module-wide
lock _ldapmodule_lock.
and wanted to know more about this.
Finally I found every object contains its own lock ! (if the used ldap
library is reentrant)
and their was no bottleneck. I was happy :-)
But _ldap_function_call is still used to call _ldap.initialize at some place
[root@fc6-eg ldap]# grep _ldap.initialize *.py
ldapobject.py: self._l =
ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
ldapobject.py: self._l =
ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
ldapobject.py: self._l = self._ldap_call(_ldap.initialize,self._uri)
why not to replace the use of _ldap_function_call by the more
appropriate _ldap_call, already used in the last line ! And that way
debugging will provide and uri for initialise call!
here is the patch
*** ldap.orig/ldapobject.py Sat Jan 27 01:57:50 2007
--- ldap/ldapobject.py Sun Jan 28 02:34:56 2007
***************
*** 66,72 ****
self._trace_stack_limit = trace_stack_limit
self._uri = uri
self._ldap_object_lock = self._ldap_lock()
! self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri)
self.timeout = -1
self.protocol_version = ldap.VERSION3
--- 66,73 ----
self._trace_stack_limit = trace_stack_limit
self._uri = uri
self._ldap_object_lock = self._ldap_lock()
! self._l = self._ldap_call(_ldap.initialize,self._uri)
!
self.timeout = -1
self.protocol_version = ldap.VERSION3
***************
*** 732,738 ****
))
try:
# Do the connect
! self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri)
self._restore_options()
# StartTLS extended operation in case this was called before
if self._start_tls:
--- 733,740 ----
))
try:
# Do the connect
! self._l = self._ldap_call(_ldap.initialize,self._uri)
!
self._restore_options()
# StartTLS extended operation in case this was called before
if self._start_tls:
--
Alain Spineux
aspineux gmail com
May the sources be with you
|
