On Mon, May 10, 2010 at 11:15:59AM -0400, Pavel Ivanov scratched on the wall: > > Any ideas about how to implement a DB in shared memory? > > It's impossible with current SQLite code base. Even if you try to > implement your own database cache and will allocate it in some shared > memory it won't work because along with cache pages SQLite also stores > some internal information which should be bound to one process.
Yes... in-memory DBs are strongly tied to the database connection that creates them. They cannot be accessed by multiple processes. The only option for a true multi-access in-memory DB would be to write a VFS module. That's a somewhat non-trivial piece of code. The other option would be to use a standard file-based DB and just turn all the syncs off. Most of the DB would live in the OS disk cache, and you'd get nearly the same performance. > But the best solution will be to use standard IPC mechanisms and to > not make things over-complicated. Generally databases should be used > if you need at least some kind of persistence between process > restarts. Agreed. There are other, likely better, ways of solving this problem. Protected queues for IPC message passing is an old, old problem. Many advanced threading libs have the tools for this. If not, there are many different message-passing libraries out there like MPI. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
