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
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,
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 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
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
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
-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
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
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 but
-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 operation
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
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
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
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
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 more
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:
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, and
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?
thanks for any info.
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
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
20 matches
Mail list logo