From owner-freebsd-stable  Thu Apr 19 14: 0:44 2001
Delivered-To: freebsd-stable@freebsd.org
Received: by hub.freebsd.org (Postfix, from userid 618)
	id 5A53A37B424; Thu, 19 Apr 2001 14:00:36 -0700 (PDT)
Subject: Re: FreeBSD 4.3-RC5 now on ftp.freebsd.org
In-Reply-To: <200104192001.QAA60154@cs.rpi.edu> from "David E. Cross" at "Apr 19, 2001 04:01:16 pm"
To: crossd@cs.rpi.edu (David E. Cross)
Date: Thu, 19 Apr 2001 14:00:36 -0700 (PDT)
Cc: jkh@osd.bsdi.com, stable@FreeBSD.org, developers@FreeBSD.org,
	crossd@cs.rpi.edu
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-Id: <20010419210036.5A53A37B424@hub.freebsd.org>
From: wpaul@FreeBSD.ORG (Bill Paul)
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Yes, I would agree with that.  I needed to hack the scripts here to mount_mfs
> and cp files back and forth a few times to get everything to work correctly,
> but it does work without panic-ing the system.  I can post patches if people
> would find that helpfull.
> 
> (I am still working on ypserv as well, the problems run very deep in that
> code.  Once you know where to look they start popping up all over the place. 
> Just as a sample cosider the code:
> 
> 	qhead.cqh_head->dbptr->key = key->data;
> 
> Where "key" is a DBT* that was passed back from the berkley db routines...
> now consider a few more database requests come in before that record is accessed again and all of a sudden 'key' isn't pointing at what you originally set it
> to.)

Uh. Look closer. No no, closer. The key/size members in the cached
database handle are used by the first/next routines to keep an eye on
where we are in the database so we can match a database handle with an
ongoing first/next enumeration request. (That is, where the client
does a yp_first() and then a series of yp_next()s to dump out all of
the entries in a map. Things like getpwent() and getgrent() do this,
and it gets *really* slow if you have to start from the top and linear
search down for each yp_next() request, which is what you'd have to do
since the Berkeley DB hash database method doesn't let you position the
'cursor' at arbitrary locations. This trick lets us say: "Hey! This is
the same handle we used for the last yp_next() request, and it's positioned
at the right place in the database for us to pick up where we left off.
Let's use this handle again.")

The key pointer remains valid up until the next request is made, which
could be a yp_first_record(), yp_next_record() or yp_get_record().

- yp_first_record(): we set the key pointer to the current key
- yp_next_record: we set the key pointer to the current key
- yp_get_record(): we set the key pointer to NULL

Every time we do a new database access, we update the key pointer.
It can never point off into the weeds because it never becomes stale.

I admit, the optimization is grody. Had I used the btree database method,
this wouldn't have been necessary, but something told me not to do that.
If you can prove that using the btree method would be faster, you can
re-write the yp_dblookup.c module to use it.

-Bill

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message