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

Reply via email to