A "position" is politics, not science. Warnings about the use of threads are based on science, and advise you to avoid them if possible for your own protection.
I see ill conceived programs using threads which go to complex synchronization to achieve the equivalent of single stream execution but with much greater overhead. A KISS situation. James Gregurich wrote: > thanks for the info. That should work for me. > > Given the industry is going multicore and 16-core macintoshes for your > grand-mother are just a few years away, I recommend you rethink your > position on the use of threading. Apple is heavily pushing parallelism > on its developers. NSOperation is a major part of that effort. As I > understand it, MS is developing their copy of NSOperation for VS2010. > The development landscape is only going to get more threaded as time > goes on. > > -James > > > >> On Apr 29, 2009, at 10:03 PM, James Gregurich wrote: >> >> >>> howdy! >>> >>> question: >>> >>> for an in-memory db with the threading mode set to serialized, is >>> >> the >> >>> internal mutex held for an entire transaction so that one thread >>> >> won't >> >>> access the db while another one is in the middle of a transaction >>> >> with >> >>> multiple insert statements? >>> >> No. But the mutex is recursive. So you can get a copy of it using >> sqlite3_db_mutex() then lock it yourself using sqlite3_mutex_enter()/ >> leave(). >> >> Also remember: You should not be using threads. Threads will bring >> only grief and woe. On your own head be it. >> >> >> >> D. Richard Hipp >> drh at hwaci.com >> >> > _______________________________________________ > 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
