ok. I think I see what you are suggesting. You want to provide a mechanism to create memory files that SQLite thinks are disk files....that way you could create multiple connections to them.
an interesting idea. However, that may be more effort that I can justify at this point. I'll think about it. yes. I am fluent in STL. On Apr 19, 2008, at 1:19 PM, Virgilio Alexandre Fornazin wrote: > 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
