On Thu, 2007-05-17 at 18:26 -0400, Martin Gentry wrote: > 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.
The current official position, as I understand it, is that you can pass handles between threads. There are no known reasons that this will not work. But it's been a source of bugs in the past, and I personally wouldn't risk it if I had the choice. Especially if I thought the code could be deployed with a variety of different OS's or kernel versions. But that's just an opinion. Tricky things, threads. Dan. > ----- 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] > ----------------------------------------------------------------------------- > ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
