I describe reality. Someone has to be the arbiter of "better." Generally, that arbiter is the guy handing out the research grants.
On May 1, 2009, at 5:33 AM, John Stanton wrote: > > 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users