Richard, It makes sense, but I see here some possibility of future confusion. Correct me if I'm wrong. Currently if I have a vfs that requires special preparations (for example, decompression), I have two choices, either provide V2 interface or emulate memory-mapping by allocating my own blocks of memory in xFetch and deallocating in xUnfetch. If future V4 IO routines introduce something new, one will not have the first option. So anyone in the future should be aware that there are two points where data can be needed and since one expects filling previously allocated block and another expects pointer to the data, the complexity of understanding will grow. Or is there a simple way to disable xFetch/xUnfetch on the VFS level?
Max On Mon, Apr 8, 2013 at 3:33 PM, Richard Hipp <d...@sqlite.org> wrote: > On Mon, Apr 8, 2013 at 6:12 AM, Max Vlasov <max.vla...@gmail.com> wrote: > > > But I also noticed that if I provide > > version 2 of vfs, I won't get benefits of file-mapping > > > > That's how we implement backwards compatibility to legacy VFSes. > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
