Imagine the following cenario (I assume you know c++ stdlib) A map of strings (filenames) to in-memory file handlers (the objects that will handle the shared memory or heap files).
These files handlers will exists until the process exists and do not receive a delelefile() vfs call. File handlers can synchronize RW-Locks using internal mutex/criticat sections/semaphores/spin locks, etc. When you create a new file in vfs, a new handler is created and assigned to that filename and registered in this map. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Gregurich Sent: sábado, 19 de abril de 2008 17:02 To: General Discussion of SQLite Database Subject: Re: [sqlite] multiple writers for in-memory datastore I don't immediately see how that would solve the problem. The limitation of interest here (based on my perhaps limited understanding) is that locking has file-level granularity. I don't immediately see how a VST implementation would allow for changing the locking granularity of the overall system. -James On Apr 19, 2008, at 12:03 PM, Virgilio Fornazin wrote: > what about creating a VFS for such task ? Can be accomplished in > many ways, > using heap memory, shared memory... not so easy to do, but not much > complicated too... locking can be provided by multiple-readers > single-writers locks strategies, etc... > > On Sat, Apr 19, 2008 at 2:29 PM, James Gregurich <[EMAIL PROTECTED]> > wrote: > >> >> oh good! That isn't the version that ships with Leopard, but I can >> live with deploying my own version as part of my app. >> >> Will l get the writer parallelism I'm after as long as each thread >> writes exclusively into its own attached db? >> >> >> in other words....two bulk insert operations going on simultaneously >> on the same connection but each insert operation going into a >> different attached in-memory db. >> >> >> On Apr 19, 2008, at 9:20 AM, Dan wrote: >> >>> >>> On Apr 19, 2008, at 6:06 AM, James Gregurich wrote: >>> >>>> >>>> I'll ask this question. The answer is probably "no," but I'll ask >>>> it >>>> for the sake of completeness. >>>> >>>> >>>> Suppose I created an in-memory db. I use the attach command to >>>> associate an additional in-memory db. Suppose I assign the main >>>> db to >>>> thread 1 and the associated db to thread 2. Can I share the >>>> connection >>>> across the 2 threads if each thread works exclusively in its own >>>> db? >>>> >>>> I am aware that the connection is generally not threadsafe, but >>>> will >>>> it work if the two threads don't operate on the same db at the same >>>> time? >>> >>> As of 3.5, sqlite connections are threadsafe by default. With >>> earlier versions, this trick will not work. >>> >>> Dan. >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
