With all due respect, science itself is a set of "positions" (opinions) which are endorsed by small group of people as official doctrine after appropriate study. Saying "A 'position' is politics, not science" is not a particularly meaningful statement. If you want to argue that point, feel free to send me a private email.
My threaded application works pretty darn well. I can process thousands of print industry files on an 8-core system keeping the cores busy without lagging the GUI for other applications. Just because many people create ill conceived programs doesn't mean threaded programs are inherently doomed to be ill-conceived. The development tools and techniques for building concurrent systems are advancing and making concurrency quite feasible. James Gregurich Engineering Manager Markzware On Apr 30, 2009, at 5:01 AM, John Stanton wrote: > 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
