On 2/14/17, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > Due to memory constraints > (at least 1MB is consumed per connection!), only one database > connection is used. Any thread may acquire and use this one database > connection at any time.
<rant> This is yet another reason why I say "threads are evil". For whatever reason, programmers today think that "goto" and pointers and assert() are the causes of all errors, but threads are cool and healthful. Entire programming languages are invited (I'm thinking of Java) to make goto and pointers impossible or to make assert() impossible (Go) and yet at the same time encourage people to use threads. It boggles the mind.... </rant> > > If we have two threads executing sqlite3_step() on the same connection > and using their own prepared statement, is there any magic in sqlite3 > which would keep sqlite3_step() and sqlite3_column_foo() from > consuming (or disrupting) the results from the other thread? Yes, that is suppose to work. If you find a (reproducible) case where it does not, we will look into it. > > In this use case is sqlite3 usage "thread safe" or is behavior > unstable due to sqlite3_step(), sqlite3_reset(), and result column > accessors accessing/disrupting data from the result set of the other > thread? > -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
