Date: Sat, 19 Oct 1996 19:01:11 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@glue.umd.edu (Chuck Robey) Cc: terry@lambert.org, thorpej@nas.nasa.gov, dnelson@emsphone.com, ache@nagual.ru, deraadt@theos.com, hackers@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/db/hash hash_buf.c Message-ID: <199610200201.TAA03344@phaeton.artisoft.com> In-Reply-To: <Pine.OSF.3.95.961019201850.8857C-100000@baud.eng.umd.edu> from "Chuck Robey" at Oct 19, 96 08:22:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > It seems to me that the correct approach is to provide a conditional > > interface to any caching library system -- whether it be db or stdio > > or some other interface -- to explicitly dump the cache contents, and > > then expect the application writers to take note of potential problem > > situations and generate correct code to deal with them. > > If one could set such a flag globally, then all the stuff in libc that > uses malloc could be written to look at that global flag and DTRT, without > changing any of the interfaces at all. Set the flag in crt0 to the > current action (no action) and things in fact would not change at all, no > speed penalty. Doesn't sound like a bad idea at all. Well, you would hope that you could set the flag locally, where it's supported, and it would be globally supported. Basically, you'd have a linker set initialization function for an affected library, and when the program started, it would call the setup functions, which would in turn obey the flag, if set. Alternately, you could eat a compare on each "free" event; it's not much overhead, but being a computational nanosecond kind of person, I'd like to avoid all overhead. 8-). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610200201.TAA03344>