Quoth Richard Hipp <d...@sqlite.org>, on 2013-04-04 08:02:34 -0400: > By making use of memory-mapped I/O, the current trunk of SQLite (which will > eventually become version 3.7.17 after much more refinement and testing) > can be as much as twice as fast, on some platforms and under some > workloads. [...]
I'm curious how you plan to handle reliability against I/O errors in mmap mode. My understanding is that achieving this in a library without potentially interfering with the host program operation is extremely difficult on Linux, and is reliable but requires significant platform-specific juggling on Windows; I don't know as much about other OSes. Specifically, an I/O error faulting in an mmapped page can deliver a SIGBUS to the thread. If unhandled, this will crash the entire host application, and setting local signal handlers for just that case is hard-to-impossible to do reliably from libraries without a lot of coöperation from both the host application and any other library that needs the same thing. A possible way to partially test this (which I haven't tried against this SQLite yet) is to stop the reading process right before it reads a page that it has not yet touched, truncate the file to a length less than the page offset, then resume the original process. It now occurs to me (which it did not before) that WAL mode also has this danger to some extent with the -shm files, but this is mitigated mainly because (a) WAL mode must be turned on explicitly for a given database file and secondarily because (b) AIUI, the -shm files are only kept while any processes have the database open, and are small enough that they are very likely to stay in memory the entire time. (Even so, it may be worthwhile to mlock the regions before using them, which a quick grep does not find currently, but that is an open question, not a hard recommendation.) ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
