> I will take a look at reworking the
>
> On 08/22/10 10:09 AM, masar...@aero.polimi.it wrote:
>>> My concern is: can you guarantee that the occurrences of
>>> locking/unlocking
>>> those additional mutexes, combined to the existing ones, do not result
>>> in
>>> deadlocks? I mean: did you expli
While I'm making the second round of changes, I have a follow up question.
Is there any objection to me removing the THR_LWP code from libldap_r
as part of this ITS?
Unless there is an objection, I plan to have that code removed from my next
round of diffs.
[I looked it up] For the record, Sun
I understand w.r.t. the depreciated and additional error functions.
They are not specifically required for anything we are doing, I saw
them as convenience APIs. I will remove them as part of my next
round code changes.
I also wasn't aware that there were multiple flavors of the same
API signatu
I will take a look at reworking the
On 08/22/10 10:09 AM, masar...@aero.polimi.it wrote:
My concern is: can you guarantee that the occurrences of locking/unlocking
those additional mutexes, combined to the existing ones, do not result in
deadlocks? I mean: did you explicitly check all possible
On 08/20/10 05:01 PM, masar...@aero.polimi.it wrote:
One thing I'd like to ask is: you introduce a few additional mutexes:
ldapoptions -> ldo_mutex
ldapcommon -> ldc_msgid_mutex, ldc_abandon_mutex
in addition of the already existing
ldap -> ld_conn_mutex, ld_req_mutex, ld_res_mutex
that
On Aug 18, 2010, at 4:34 PM, Howard Chu wrote:
> my purpose in directing the conversation here is to discuss why. It's not
> clear to me that this old draft is still viable or desirable. As we've talked
> about many times before, the C API is a huge mess and we need to toss the
> current one o
> Doug,
>
> a list of relatively quick comments, as I didn't go into too much detail
> in the analysis of each bit of your work.
>
> I think your patch contains at least three levels of modifications; they
> all make sense separately and incrementally, so I think we should revise
> them separately.
Doug,
a list of relatively quick comments, as I didn't go into too much detail
in the analysis of each bit of your work.
I think your patch contains at least three levels of modifications; they
all make sense separately and incrementally, so I think we should revise
them separately.
1) "cosmetic
On 08/18/10 06:34 PM, Howard Chu wrote:
Kurt Zeilenga wrote:
Doug,
I note as a general rule, which I will follow in this case, I don't
review
patches authors would like included in OpenLDAP Software until they
have been
formally submitted for review.
While the ITS submission provides for a
Kurt Zeilenga wrote:
Doug,
I note as a general rule, which I will follow in this case, I don't review
patches authors would like included in OpenLDAP Software until they have been
formally submitted for review.
While the ITS submission provides for a review of what was done, my purpose in
dir
> I would like to propose a patch to the OpenLDAP
> C APIs to support the operation thread safe features
> described in the draft-zeilenga-ldap-c-api-concurrency
> drafts.
>
> The enhancements add upwardly compatible interfaces
> and should have no behavioral regressions w.r.t. any
> existing lib
Doug,
I note as a general rule, which I will follow in this case, I don't review
patches authors would like included in OpenLDAP Software until they have been
formally submitted for review.
Regards, Kurt
12 matches
Mail list logo
