Re: [sqlite] One more SQLite threading question
This almost immediately raises library routine called out of sequence. It occurs as soon as the processing of A and B overlap, that means A is preparing statement #2 while B is still executing #1. Have you tried using Mutex or some other way to prevevent really simultaneous calling of SQLite methods? My guess that it should work well then, but I haven't tried it myself... Jiri - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Re: Problem with Unicode surrogates
The Unicode standard is beside the point. There is lots of code that does not handle charsets and encodings correctly, which can open vulnerabilities to metacharacter injection. (Examples of this class of problem are SQL injection, XSS and format string exploits.) I can't agree. SQLite itself wouldn't be vurnelable at all by accepting any UTF-16 string (including invalid ones). Certainly, it could cause problems to some applications using SQLite, but SQLite can't be responsible for poorly written applications using it, can it? Anyway, it certainly can't be called a bug if SQLite returns error when I try to prepare an SQL statement with invalid characters. However, it should be clear what SQLite considers as an invalid character, is it only an unpaired surrogate, anything that Unicode standard defines as a 'noncharacter' or even any character that currently isn't defined by Unicode standard (which would be pretty bad in my opinion)? Re. that 0xE000 character, should I submit a bugreport somewhere? Thanks, Jiri - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Re: Problem with Unicode surrogates
On Thu, 2007-05-17 at 16:54 +0200, Jiri Hajek wrote: The Unicode standard is beside the point. There is lots of code that does not handle charsets and encodings correctly, which can open vulnerabilities to metacharacter injection. (Examples of this class of problem are SQL injection, XSS and format string exploits.) I can't agree. SQLite itself wouldn't be vurnelable at all by accepting any UTF-16 string (including invalid ones). Certainly, it could cause problems to some applications using SQLite, but SQLite can't be responsible for poorly written applications using it, can it? Anyway, it certainly can't be called a bug if SQLite returns error when I try to prepare an SQL statement with invalid characters. However, it should be clear what SQLite considers as an invalid character, is it only an unpaired surrogate, anything that Unicode standard defines as a 'noncharacter' or even any character that currently isn't defined by Unicode standard (which would be pretty bad in my opinion)? Re. that 0xE000 character, should I submit a bugreport somewhere? You already did. Thanks. http://www.sqlite.org/cvstrac/chngview?cn=4017 In general, formal bug reports can be submitted by clicking [Ticket] on this page: http://www.sqlite.org/cvstrac/ Dan. Thanks, Jiri - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Re: Problem with Unicode surrogates
Re. that 0xE000 character, should I submit a bugreport somewhere? You already did. Thanks. http://www.sqlite.org/cvstrac/chngview?cn=4017 Ok, I reviewed the sources (utf.c) and I'd say that it's still incorrect. Actually, it doesn't test for surrogates at all, the problem I was experiencing was caused by the fact that SQLite reads unallocated memory when there's an unpaired surrogate present as the last character of string - see READ_UTF16LE macro. Jiri - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
However, it would be too time consuming to serialize every call to sqlite3_step(), so I wonder whether it can be called in another thread. This almost immediately raises library routine called out of sequence. It occurs as soon as the processing of A and B overlap, that means A is preparing statement #2 while B is still executing #1. Have you tried using Mutex or some other way to prevevent really simultaneous calling of SQLite methods? My guess that it should work well then, but I haven't tried it myself... Yes I did the same experiment with a lock that made thread A wait until B was finished. So actually only one thread can be active at the time. I don't see how the outcome of this experiment can be of any interest, as there is no time reduction any longer. But your guess is right that, it works. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
Just as an FYI on the threading ... http://www.sqlite.org/capi3ref.html#sqlite3_open The returned sqlite3* can only be used in the same thread in which it was created. It is an error to call sqlite3_open() in one thread then pass the resulting database handle off to another thread to use. This restriction is due to goofy design decisions (bugs?) in the way some threading implementations interact with file locks. -martin - Original Message - From: Ed Pasma [EMAIL PROTECTED] To: sqlite-users@sqlite.org Sent: Thursday, May 17, 2007 4:18 PM Subject: Re: [sqlite] One more SQLite threading question However, it would be too time consuming to serialize every call to sqlite3_step(), so I wonder whether it can be called in another thread. This almost immediately raises library routine called out of sequence. It occurs as soon as the processing of A and B overlap, that means A is preparing statement #2 while B is still executing #1. Have you tried using Mutex or some other way to prevevent really simultaneous calling of SQLite methods? My guess that it should work well then, but I haven't tried it myself... Yes I did the same experiment with a lock that made thread A wait until B was finished. So actually only one thread can be active at the time. I don't see how the outcome of this experiment can be of any interest, as there is no time reduction any longer. But your guess is right that, it works. - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
Martin Gentry [EMAIL PROTECTED] wrote: Just as an FYI on the threading ... http://www.sqlite.org/capi3ref.html#sqlite3_open The returned sqlite3* can only be used in the same thread in which it was created. It is an error to call sqlite3_open() in one thread then pass the resulting database handle off to another thread to use. This restriction is due to goofy design decisions (bugs?) in the way some threading implementations interact with file locks. That restriction is due to bugs in GLIBC or maybe the Linux Kernel (I'm not sure which) which have been resolved. And for that matter, more recent versions of SQLite work around the bugs even if they are there. So you can mostly ignore this now. Mostly. -- D. Richard Hipp [EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
Can you be a bit more specific? :-) I ask because this is immediately relevant to some code I'm writing today, and have been operating on the understanding that I should honour the restriction. I'm fine with honouring the restriction if required, but it might make my life easier if I don't have to. - Original Message - From: [EMAIL PROTECTED] To: sqlite-users@sqlite.org Sent: Thursday, May 17, 2007 5:01 PM Subject: Re: [sqlite] One more SQLite threading question Martin Gentry [EMAIL PROTECTED] wrote: Just as an FYI on the threading ... http://www.sqlite.org/capi3ref.html#sqlite3_open The returned sqlite3* can only be used in the same thread in which it was created. It is an error to call sqlite3_open() in one thread then pass the resulting database handle off to another thread to use. This restriction is due to goofy design decisions (bugs?) in the way some threading implementations interact with file locks. That restriction is due to bugs in GLIBC or maybe the Linux Kernel (I'm not sure which) which have been resolved. And for that matter, more recent versions of SQLite work around the bugs even if they are there. So you can mostly ignore this now. Mostly. -- D. Richard Hipp [EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
Ed Pasma wrote: However, it would be too time consuming to serialize every call to sqlite3_step(), so I wonder whether it can be called in another thread. This almost immediately raises library routine called out of sequence. It occurs as soon as the processing of A and B overlap, that means A is preparing statement #2 while B is still executing #1. Have you tried using Mutex or some other way to prevevent really simultaneous calling of SQLite methods? My guess that it should work well then, but I haven't tried it myself... Yes I did the same experiment with a lock that made thread A wait until B was finished. So actually only one thread can be active at the time. I don't see how the outcome of this experiment can be of any interest, as there is no time reduction any longer. But your guess is right that, it works. How would multiple threads be faster than a single one when you are accessing a single resource? - To unsubscribe, send email to [EMAIL PROTECTED] -
