On Fri, Aug 12, 2016 at 12:02 PM, Warren Young <w...@etr-usa.com> wrote:
> On Aug 11, 2016, at 7:50 PM, Scott Robison <sc...@casaderobison.com> > wrote: > > > >> It’d be a lot of work just to avoid rebuilding for 64-bit, but maybe it > >> would be an interesting project for someone. Like a master’s university > >> project, maybe. > >> > > > > At first I thought to myself that a custom memory allocator for SQLite > > could do this, but the real problem would be once a pointer is given to > > SQLite, it is expected that pointer will be valid until disposed of > > Yeah, you’d need something like the handle lock/unlock pattern you see on > some OSes, where the app generally holds only handles long-term, locking > them down to yield a pointer only for the duration of a single function > invocation at most. > > > Certainly a valuable tool for heavy processes that need to run on 32-bit > > PAE hardware with > 4 GiB of addressable ram. Anyone want to start work > on > > SQLHeavy? ;) > > I was thinking more “valuable for the educational experience” than > valuable in any practical sense, given the easy availability of 64-bit OSes > and hardware. > Well, it certainly was practical at one point in time. I'm sure there are still apps running on old servers that depend on its existence. As for writing new code today that utilizes it, the utility is minimal if it even exists. -- Scott Robison _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
