[sqlite] SQL sintaxe
Hello, CREATE TABLE [pcprod] ( [codigo] NVARCHAR(20) NOT NULL ON CONFLICT ABORT PRIMARY KEY, [descr] NVARCHAR(40), [marca] NVARCHAR(20), [codigoint] NVARCHAR(20), [preco] NUMERIC(5, 7), [preco2] NUMERIC(5, 7)); CREATE TABLE [pcdesc] ( [codigo] NVARCHAR(20), [qtde] NUMERIC(5, 6), [loja] INTEGER, [secao] INTEGER, [coletor] INTEGER, [hora] NVARCHAR(8), [dia] NVARCHAR(8), [chave] GUID PRIMARY KEY); This "Select " is ok. SELECT SUM(qtde) AS cont, codigo FROM pcdesc GROUP BY codigo" But I need the fields "*marca*" and "*descr*". select SUM(qtde) AS cont, descr , codigo FROM pcdesc GROUP BY codigo, descr? Wrong. Thanks a lot, Ernany ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] INSERT may succeed when another process has a read lock
I am trying to understand the behavior of the engine in this instance: Process 1 obtains a SHARED lock on a database. Process 2 then steps an INSERT statement and gets SQLITE_BUSY as expected. However, Process 2 then steps a different INSERT statement on the same connection, and it returns SQLITE_DONE, with 1 change reported. This is despite the active SHARED lock. Fortunately, this change never actually shows up in the database. The key is, this only happens when I do not reset the first INSERT immediately after the BUSY notification. If I reset it, the second INSERT correctly returns BUSY as well. Now, I have determined it is good practice to do a reset in this case for other reasons, and it is no problem. However, what I would like explained if possible is why a reset on statement 1 affects the locking behavior of statement 2. To my understanding a reset is only required when you wish to reuse a statement or to ensure locks are dropped. But in this case the behavior is simply odd. My only guess is that the library is in an internally inconsistent state, and this is actually a "misuse of interface" which is not heuristically detected by the engine, and so all bets are off. I have a short piece of code which reproduces the problem on this OS X system on 3.6.13 and on 3.1.3 (changing prepare_v2 to prepare). Instructions are in the C code comments. In short, initialize the DB with the .sql file; obtain a shared lock on the database with the sqlite3 shell; then run the C code. The second insert should "succeed". http://3e8.org/pub/write-misuse-demo.sql http://3e8.org/pub/write-misuse-demo.c Jim -- j...@3e8.org / 0x43340710 / 517B C658 D2CB 260D 3E1F 5ED1 6DB3 FBB9 4334 0710 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Names of Indexes (CREATE INDEX)
you can name indexes as you wish. if you use select - you should specify coluns names. engine well decide what index to use depend on CREATE INDEX statement and you SQL query. On Saturday 02 May 2009 02:45:03 a a wrote: > Do index names need to be different from field names? > When doing selects on indexed fields, can I use the field name, or must I > use the index name? > > I just want normal indexes, i'm not looking to create indexes for multiple > fields. > > Can I say: CREATE INDEX x ON t (x); ? > or does it have to be: CREATE INDEX index_t_x ON t (x); ? > assuming the latter, can I say SELECT * FROM t ORDER BY x; or do I have to > say ORDER BY index_t_x; to receive the speed benefit of the index. > > I tried CREATE INDEX x ON t (x); in SQLite3.exe, and no error was reported, > but I don't want to assume anything. > > This is extremely ambiguous and confusing. > I've got enough field names, I don't want to have to start dealing with > unique index names as well in SELECT/INSERT/UPDATE queries. > > Thanks for the help. Feeling very frustrated atm. > ___ > 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
Re: [sqlite] Names of Indexes (CREATE INDEX)
a a wrote: > Do index names need to be different from field names? No. > When doing selects on indexed fields, can I use the field name, or > must I use the index name? You must use the field name, you cannot use index name. An index will be used automatically if the engine deems it beneficial. > Can I say: CREATE INDEX x ON t (x); ? Yes. > or does it have to be: CREATE INDEX index_t_x ON t (x); ? This is valid, too. > assuming the latter, can I say SELECT * FROM t ORDER BY x; Yes. > or do I > have to say ORDER BY index_t_x; No. In fact, it won't work, you'll get a syntax error. > This is extremely ambiguous and confusing. What specifically seems to be the problem? > I've got enough field names, I don't want to have to start dealing > with unique index names as well in SELECT/INSERT/UPDATE queries. Wherever did you get the idea in the first place? Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] mutex and begin/end transaction
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: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] 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 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 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Names of Indexes (CREATE INDEX)
Do index names need to be different from field names? When doing selects on indexed fields, can I use the field name, or must I use the index name? I just want normal indexes, i'm not looking to create indexes for multiple fields. Can I say: CREATE INDEX x ON t (x); ? or does it have to be: CREATE INDEX index_t_x ON t (x); ? assuming the latter, can I say SELECT * FROM t ORDER BY x; or do I have to say ORDER BY index_t_x; to receive the speed benefit of the index. I tried CREATE INDEX x ON t (x); in SQLite3.exe, and no error was reported, but I don't want to assume anything. This is extremely ambiguous and confusing. I've got enough field names, I don't want to have to start dealing with unique index names as well in SELECT/INSERT/UPDATE queries. Thanks for the help. Feeling very frustrated atm. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] mutex and begin/end transaction
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 topic. It should get back to Sqlite. James Gregurich wrote: > 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 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Strict affinity again
* D. Richard Hipp: > SQLite is strongly typed, Curiously, it's even more strongly typed than SQL: sqlite> SELECT 1 = '1'; 0 fw=> SELECT 1 = '1'; ?column? -- t (1 row) (In SQL, quoted values are not of string type, but their type is inferred from context.) ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
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 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
Re: [sqlite] Errors with quickstart.html's C example
2009/5/1 John Stanton : > What is your make file? It seems to be missing a link library. I hadn't gotten to that point yet. But, as the other email said, linking to sqlite3 does magic. -- Samuel 'Shardz' Baldwin - staticfree.info/~samuel ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Errors with quickstart.html's C example
What is your make file? It seems to be missing a link library. Samuel Baldwin wrote: > Howdy. When I try to compile the small C program at the bottom of > http://www.sqlite.org/quickstart.html , I get the following errors: > > arrakis^library% gcc test.c > test.c: In function ‘main’: > test.c:21: warning: incompatible implicit declaration of built-in > function ‘exit’ > test.c:27: warning: incompatible implicit declaration of built-in > function ‘exit’ > /tmp/ccYuZFw7.o: In function `main': > test.c:(.text+0xc0): undefined reference to `sqlite3_open' > test.c:(.text+0xd2): undefined reference to `sqlite3_errmsg' > test.c:(.text+0xf4): undefined reference to `sqlite3_close' > test.c:(.text+0x123): undefined reference to `sqlite3_exec' > test.c:(.text+0x14f): undefined reference to `sqlite3_free' > test.c:(.text+0x158): undefined reference to `sqlite3_close' > collect2: ld returned 1 exit status > > The warnings about exit() are removed if I add #include , > but then I'm left with: > > arrakis^library% gcc test.c > /tmp/ccENlzA6.o: In function `main': > test.c:(.text+0xc0): undefined reference to `sqlite3_open' > test.c:(.text+0xd2): undefined reference to `sqlite3_errmsg' > test.c:(.text+0xf4): undefined reference to `sqlite3_close' > test.c:(.text+0x123): undefined reference to `sqlite3_exec' > test.c:(.text+0x14f): undefined reference to `sqlite3_free' > test.c:(.text+0x158): undefined reference to `sqlite3_close' > collect2: ld returned 1 exit status > > I'm really not sure what else to do. I've tried this on two machines > running two seperate linux distributions, and friends have confirmed > the same error on yet other machines. Is the sample code just > outdated? Looking over it and sqlite3.h makes me think it should work. > > I'm running sqlite3 3.6.13 > > Thanks, I'm completely baffled. > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] mutex and begin/end transaction
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
Re: [sqlite] mutex and begin/end transaction
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, to have access to multiple resources. When you have multiple threads accessing one resource, such as a database, then you must have a robust synchronization method, such as a mutex, queue or similar. There is a danger that programmers will implement a busy wait to perform their synchronization and get poor performance. In some low level, low latency cases however the use of the ultimate busy wait, a spin lock, is the best approach. Pavel Ivanov wrote: > 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 danger with threading is in concurrent access to data. > > 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. And my > overall point here is that there's no universal taboo "threads are > evil in all cases". It totally depends on the type of application. > > Pavel > > On Thu, Apr 30, 2009 at 2:54 PM, Roger Binns wrote: >> -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 (forking etc) but in the one that >> uses threading, each thread handles a connection and does not handle or >> share any data with other threads during its operation on that >> connection. For the non-Windows worker (MPM) it also uses multiple >> processes with multiple threads and the processes exit after handling a >> certain number of requests. >> >> As an example you can read about mod_wsgi which provides for running >> Python code as though it was CGI - see http://code.google.com/p/modwsgi/ >> >> Roger >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iEYEARECAAYFAkn58/MACgkQmOOfHg372QSoOQCfXvz8ef7vS0HP/Uc9hZ/1BQSO >> Cw0AoMXzgpNwO0PA5uMBvG/DB2Y3lKHG >> =Cage >> -END PGP SIGNATURE- >> ___ >> 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
Re: [sqlite] mutex and begin/end transaction
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 in an uncontrollable environment (i.e. a consumer desktop computer) when I can just use NSOperation, boost::thread, and boost::mutex to build a single-process solution that shares data in a normal way between tasks? James Gregurich Engineering Manager Markzware On Apr 29, 2009, at 11:23 PM, Roger Binns wrote: > -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 cpu/core and large memory. > Having the same memory addressed (which is what threading does) across > multiple concurrently executing cpus/cores causes cache thrashing, > memory contention, frequent use of memory barriers for synchronization > (which also slows things down) and as memory becomes attached to > individual cpus leads to access being over hypertransport/csi. > > Far better is using multiple processes which don't have those > issues. A > good example application to study is Google Chrome which uses multiple > processes prolifically - each tab is a separate process, as well as > the > various plugins, languages etc. Each process can be appropriately > locked down using the principle of least privilege. If you use > threads > then typically they all have permission to do anything the process > could do. > > (Also the multi-process approach is way easier to test, record/replay > and is more deterministic) > > Erlang is also worth studying. It only has single threaded processes > (although the processes are lighter weight than operating system > processes). > >> NSOperation is a major part of that effort. > > If the "single encapsulated task" doesn't go around concurrently > touching bits of memory then it could be shunted to a separate process > anyway. > > The danger from threads is not the threads themselves, but the > concurrency. It is virtually impossible to prove that a threaded > process does the concurrency correctly under all circumstances. If > you > eliminate the concurrency then you can use multiple processes, and can > usually even make it scale over multiple machines! > > Roger > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkn5Q9MACgkQmOOfHg372QSS/QCfSje/tyX0hmidHyubVKqrXlHt > Sq0AoKEbmcwx/fmAFtcVeMjbcUgN8dr3 > =8lUQ > -END PGP SIGNATURE- > ___ > 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
Re: [sqlite] A memvfs for loading/saving database from buffer
> It also sounds like you are operating in an environment that is almost > entirely reading and with lots of memory. You could still store one Yes. The memvfs requires to entirely reading the database. So this solution is just for something like addressbook application, the data for one user is small enough, we can accept to entirely read. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] A memvfs for loading/saving database from buffer
http://spserver.googlecode.com/files/spmemvfs-0.1.src.tar.gz Changes: * Modify the save callback, transfer the ownership of the buffer to callback function * Add a buffer map to pass buffer between application and sqlite3 vfs The demo code: static void * load( void * arg, const char * path, int * len ) { spmembuffer_map_t * themap = (spmembuffer_map_t*)arg; char * ret = spmembuffer_map_take( themap, path, len ); return ret; } static int save( void * arg, const char * path, char * buffer, int len ) { spmembuffer_map_t * themap = (spmembuffer_map_t*)arg; return spmembuffer_map_put( themap, path, buffer, len ); } int main( int argc, char * argv[] ) { spmembuffer_map_t * themap = spmembuffer_map_new(); spmemvfs_cb_t cb = { themap, load, save }; const char * path = "abc.db"; spmemvfs_init( &cb ); // load membuffer from file, put it into themap { char * buffer = NULL; int len = 0; buffer = read_buffer_from_file( path, &len ); spmembuffer_map_put( themap, path, buffer, len ); } // open sqlite by sqlite3_open_v2 { sqlite3 * dbHandle = NULL; char errcode = sqlite3_open_v2( path, &dbHandle, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, SPMEMVFS_NAME ); // do wahtever you want .. } // get membuffer from themap, save it to file { int len = 0; char * buffer = (char*)spmembuffer_map_take( themap, path, &len ); save_buffer_to_file( path, buffer, len ); free( buffer ); } spmembuffer_map_del( themap ); return 0; } ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Errors with quickstart.html's C example
Please, someone troll me like Theo de Raadt responding to someone saying OpenBSD is insecure... `gcc -lsqlite3 test.c' works like a charm. -- Samuel 'Shardz' Baldwin - staticfree.info/~samuel ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Errors with quickstart.html's C example
Howdy. When I try to compile the small C program at the bottom of http://www.sqlite.org/quickstart.html , I get the following errors: arrakis^library% gcc test.c test.c: In function ‘main’: test.c:21: warning: incompatible implicit declaration of built-in function ‘exit’ test.c:27: warning: incompatible implicit declaration of built-in function ‘exit’ /tmp/ccYuZFw7.o: In function `main': test.c:(.text+0xc0): undefined reference to `sqlite3_open' test.c:(.text+0xd2): undefined reference to `sqlite3_errmsg' test.c:(.text+0xf4): undefined reference to `sqlite3_close' test.c:(.text+0x123): undefined reference to `sqlite3_exec' test.c:(.text+0x14f): undefined reference to `sqlite3_free' test.c:(.text+0x158): undefined reference to `sqlite3_close' collect2: ld returned 1 exit status The warnings about exit() are removed if I add #include , but then I'm left with: arrakis^library% gcc test.c /tmp/ccENlzA6.o: In function `main': test.c:(.text+0xc0): undefined reference to `sqlite3_open' test.c:(.text+0xd2): undefined reference to `sqlite3_errmsg' test.c:(.text+0xf4): undefined reference to `sqlite3_close' test.c:(.text+0x123): undefined reference to `sqlite3_exec' test.c:(.text+0x14f): undefined reference to `sqlite3_free' test.c:(.text+0x158): undefined reference to `sqlite3_close' collect2: ld returned 1 exit status I'm really not sure what else to do. I've tried this on two machines running two seperate linux distributions, and friends have confirmed the same error on yet other machines. Is the sample code just outdated? Looking over it and sqlite3.h makes me think it should work. I'm running sqlite3 3.6.13 Thanks, I'm completely baffled. -- Samuel 'Shardz' Baldwin - staticfree.info/~samuel ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users