Many systems built on the linux 2.4 kernels contain a bug in their thread implementation: A posix advisory lock created by thread A could not be overridden or modified by thread B. In essence, linux was treating different threads within the same process as if they were different processes. Long-time users of SQLite may recall that we used to publish the restriction that SQLite database connections created in one thread could not be used in a different thread. That restriction was entirely a result of the afore mentioned bug in linux 2.4.
The unix drivers for SQLite contain a pile of ugly code to work around this bug. I would very much like to delete that code for SQLite version 3.6.7, due out in December. My question: would this cause anyone any serious hardship? My impression is that everybody who runs linux upgraded to a version 2.6 kernel at least two years ago. And even for those rare people who have not, SQLite will still continue to work correctly provided that: (1) you do not attempt to move database connections across threads. (2) you do not open connections to the same database file in two different threads of the same process. So my questions is this, really: Is there anybody who runs SQLite on a linux 2.4 kernel who either moves database connections across threads or who opens multiple connections to the same database file in separate threads of the same process? I am hoping that the answer to the previous question is "no" because I really do want to simplify the SQLite unix drivers by deleting the code that implements the linux thread/posix-lock bug work-around. D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
