try:
env CPPFLAGS="-DPTH_SYSCALL_SOFT=1" ./configure --with-threads=pth
as you likely didn't build GNU Pth with --enable-syscall-soft.
I'll update configure to remove this requirement.
Kurt
At 01:19 PM 5/19/00 -0500, Vinod Nair wrote:
>>>>
With these pth changes, multiple-writers appear to
work as expected.
However, there is another problem, this time with
readers. An
ldapsearch displays a part of the total number of
entries, then
hangs. Initiating another ldapsearch causes the
first one to
continue some more, after which both hang
again.
I suspect the select loop in daemon.c was somehow
blocking.
Rebuilding OpenLDAP with --without-yielding-select
seems to
have cured the reader problem. Does this make
sense ?
BTW, make in the tests/ directory finishes one
test, but fails
on the the second with an "address in use" error.
Also confirmed
with netstat -a, although the slapd process is not
running.
Vinod.
-----Original Message-----
From: wesley.craig@umich.edu
[mailto:wesley.craig@umich.edu]
Sent: Thursday, May 18, 2000 5:26 PM
To: Vinod Nair
Cc: openldap-software@OpenLDAP.org
Subject: Re: PTH support in OpenLDAP 1.x
> From: Vinod Nair
> On Solaris2.6, with pre-emptive threads, I've
seen "multiple
> writers" scenario occasionally core dump
(1.2.10) or hang (1.2.9).
> This is with the DirMark benchmark. Do you
have multiple writers in your
> setup ?
Yes. And we do see occasional crashes. We really
have no choice, tho,
given our high load. Also, our crash rate was no
different with PTH
than with pthreads. Numerous bug fixes have been
applied since I tried
it, tho, so PTH may improve reliability.
> By "administrative limits on searches" were
you referring to
> the sizelimit or timelimit parameters in
slapd.conf. I (and
> I'm sure others on the list too) would like
to hear about
> your performance enhancements.
I've implemented candidate limits, different from
size or time limits.
During search, particularly on un-indexed
attributes, the server loops
through large lists of entries. Given the high
time limit we set,
searches on unindexed attributes start a rather
long lived thread which
is unlikely to produce useful results. We added
code to count the
number of entries examined, the number of entries
returned, and what
the final result was. We found that searches which
examined more than
1000 entries were unlikely to ever return any
result, and the final
return was invariably "time limit
exceeded".
A candidate limit allows us to return "time limit
exceeded" (in LDAP v3
we would return "administrative limit exceeded")
in a much shorter
time, after having expended fewer
resources.
> ./configure --with-ldbm-api=db2 \
> --with-ldbm_type=btree \
> --with-threads=pth \
> --enable-rlookups=no
I believe --with-ldbm_type=btree is the
default.
:wes
<<<<