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 i
The better sales pitch and better political connections persuade the
granter of research grants. Better design and better science proves
itself by performance and success in the marketplace and bad design and
bad science consumes the grant without productivity.
This has strayed from the
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.
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
I suggest that you peruse the source code of Pthreads to get some idea
of what you do when you create a thread. They are not, as some people
appear to believe, a magic way of making the machine do more and go faster.
Threads are of course invaluable when you want one resource, such as a
user,
So, you suggest I should build a commercial desktop application (for
processing print-industry files and presenting them in a UI) in such
a way that it spawns multiple processes and communicates with them via
the filesystem or IPC APIs?
Why would I want to go to that level of complexity
James Gregurich wrote:
> I want everything in a
> nice, tidy black-box that the average joe is incredibly unlikely to
> screw up.
Err, you don't have seventy five executables and expect the user to
manually launch and click them. It is indeed all hidden. They see one
window to one program,
I can't agree that such a thing would be a good approach in a
commercial desktop application environment. I'd never deploy something
like that to millions of graphic designers. I want everything in a
nice, tidy black-box that the average joe is incredibly unlikely to
screw up. I have no
James Gregurich wrote:
> So, you suggest I should build a commercial desktop application (for
> processing print-industry files and presenting them in a UI) in such
> a way that it spawns multiple processes and communicates with them via
> the filesystem or IPC APIs?
You obviously know
Pavel Ivanov wrote:
> I understand that. That's why concurrent access should be made very
> wisely. But if this concurrent access is to some cache which allows to
> avoid huge amount of disk reads - it's worth the effort.
The operating system also just happens to have a cache that allows
avoiding
So, you suggest I should build a commercial desktop application (for
processing print-industry files and presenting them in a UI) in such
a way that it spawns multiple processes and communicates with them via
the filesystem or IPC APIs?
Why would I want to go to that level of complexity
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,
So you don't even try to argue about database-servers-like
applications? Apache maybe indeed not very good example because of
good degree of independence between threads, though I think in some
cases caching across different connections and thus across different
threads could be useful.
> The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Pavel Ivanov wrote:
> I'm curious: with all these "warnings based on science" how would you
> implement application similar to apache web-server
The danger with threading is in concurrent access to data. Apache has
several different modes of
I'm curious: with all these "warnings based on science" how would you
implement application similar to apache web-server (forget about cgis
- just plain HTML) or something like database server? I understand
that you always can write something like cgi application which run on
every web-page hit
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
James Gregurich wrote:
> 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.
Threading is the worst solution to many
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
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
19 matches
Mail list logo
