Science is the Scientific Method - observation, hypothesis and skepticism. The antithesis of politics. There are no facts in science, only observations and any hypothesis is only valid until a better one replaces it.
You describe bad, politicized science. James Gregurich wrote: > 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users