Dear all, Thank you for your help.
I tried -DSQLITE_SHM_DIRECTORY="/dev/shm" option for make file. It works very well. (One line should be added to make "/dev/shm" directory before calling file open) But, I didn't tried to use locking mode because of multiple processes can use same sqlite database at a same time. I have one more question. Following sentences are found on sqlite source. And, there is a comment about database corruption. Could I get more detailed explanation about this? .... ** can be enabled at compile-time using -DSQLITE_SHM_DIRECTORY="/dev/shm" ** or the equivalent. The use of the SQLITE_SHM_DIRECTORY compile-time ** option results in an incompatible build of SQLite; *builds of SQLite* *** that with differing SQLITE_SHM_DIRECTORY settings attempt to use the* *** same database file at the same time, database corruption will likely* *** result*. The SQLITE_SHM_DIRECTORY compile-time option is considered ** "unsupported" and may go away in a future SQLite release. .... Best wishes, Jang. 2012/3/9 Scott Hess <sh...@google.com> > On Thu, Mar 8, 2012 at 9:28 AM, Pavel Ivanov <paiva...@gmail.com> wrote: > >> Question: Does anybody know of a better way to get memory shared among > >> processes other than to create a fake file and mmap() it? Are there > some > >> magic options to mmap() (perhaps Linux-only options) that prevent it > from > >> actually writing to disk? > > > > Why don't you use shm_open() instead of a real file? I'm not sure > > though how it behaves with chroot jail. > > I do not recall the full semantics of shm_open(), but I _think_ that > it shares the sysv shared-memory problem where the memory sticks > around until explicitly deleted. Using a fake file with mmap() will > create a segment which only exists until the last process using it > goes away. This can become a resource issue on some systems. Also, > the name would have to be carefully constructed to prevent conflicts, > as the namespace may not be the same as the file path namespace (even > path-like names may have different length restrictions). Like maybe > base64(hash(canonical_path(dbpath))). > > BTW, the SQLite docs indicate that as of 3.7.4, you can arrange to use > an exclusive mode which allows WAL to work without shm. That may be a > reasonable approach for some subset of users with this kind of > problem. > > -scott > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
