One thing which is missing is pthread_once() to protect init functions.
I'll commit one for pthreads and a default version, unless someone
protests.
Then e.g. ldap_int_initialize() can use that - and if two threads call
it at the same time, one will wait for the other's initialization to
Pierangelo Masarati writes:
Well, what I really need as a baseline is if some mutex is not locked
at all. If it's not, then it's an error. If it is, it's an error
only if it's not owned by the caller.
Can you give an example of some code which needs this?
I can't offhand think of an problem
Pierangelo Masarati writes:
I fear yet more few minor concurrency issues in libldap; I'd like to be
able to assert if a mutex is locked from inside library functions,
Duh... please ignore my previous message. I forgot you said _assert_.
Well, that one isn't hard.
define an
Please remember that the lists are for discussion, not proper requests. If
you want to see this acted upon, you should probably follow an ITS as seen
at www.openldap.org/its.
On Fri, 31 Mar 2006, Xavier wrote:
Hello,
I'm having the folowing problem with OpenLDAP 2.3.20 (stable 20060227)
I've just finished going through the error report. There were 159
individual errors logged. 61 were clearly false alarms, and I've
resolved 97, with one ignored (a dead code block in liblunicode ure.c,
which we don't even use anyway).
The majority of actual bugs were memory leaks in parsing
Playing with Hallvard's thread debugging code I came into something that
looks strange: slapd does tpool init/cleanup fine, while tools don't.
Looking at things in a bit more detail, what I found out is that both
slapd create the connection_pool (while tools clearly don't need it) but
then slapd
On Fri, 2006-03-31 at 20:09 +0200, Hallvard B Furuseth wrote:
Or more generally, use my thr_debug.c package and extend
ldap_debug_thread_cond_t with the thread ID and info about whether the
mutex is locked. Get thread ID with ldap_pvt_thread_self(), compare
with ldap_pvt_thread_equal().
