Gentlefolk:
Sorry to be a 'wet blanket' here, but while this thread is an interesting
debate, *this* list is about SQLITE, not the Scientific Method... As an
observer on the sidelines, I would suggest that this discussion has strayed a
little bit off topic :-)
Uh... does anyone remember what this thread was *really* about? Oh yes,
something about Mutexes and transactions...
*** Doug Fajardo
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of James Gregurich
Sent: Friday, May 01, 2009 10:02 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] mutex and begin/end transaction
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
>>>> [email protected]
>>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>>>
>>> _______________________________________________
>>> sqlite-users mailing list
>>> [email protected]
>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>> _______________________________________________
>> sqlite-users mailing list
>> [email protected]
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> _______________________________________________
> sqlite-users mailing list
> [email protected]
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
