On Thu, 2005-06-16 at 15:25 -0400, Christopher R. Palmer wrote:
> The new misuse tests that were added were very helpful for identifying
> this. But, are the current behaviour (and tests) the "right" ones?
It is the only behavior that will work given the general brokenness of
posix locks and
My problem (ticket 1272) is that I open multiple sqlite handles in one
thread and then pass the handles to other threads to perform the work.
That is:
db1 = sqlite3_open();
db2 = sqlite3_open();
pthread_create(...,db1);
pthread_create(...,db2);
While this does not appear to be disallowed by
On Wed, 2005-06-15 at 12:43 -0400, Christopher R. Palmer wrote:
> I've temporarily placed the trace file at
>
> http://67.19.10.2/~crpalmer/sqlite-traking.gz
>
The file is named sqlite-trace-locking.gz. And it
did not containing the debugging information I need.
Perhaps you didn't compile with
D. Richard Hipp wrote:
On Wed, 2005-06-15 at 10:24 -0400, Christopher R. Palmer wrote:
In my case, I added printf statements to trace the fcntl calls and it was
the case that one thread did the fcntl to get the shared lock and then a
second thread attempted the fcntl to go from shared to
On Wed, 2005-06-15 at 10:24 -0400, Christopher R. Palmer wrote:
> In my case, I added printf statements to trace the fcntl calls and it was
> the case that one thread did the fcntl to get the shared lock and then a
> second thread attempted the fcntl to go from shared to exclusive. This is
>
The behavior of Fcntl might have changed in red hat 9 because of the change
in thread library. (I have a Enterprise version of Redhat (V3) if you want
me to test something)
Google the comp.programming.threads & linux.kernal groups.
You can specify that you want to use the older LinuxThreads
6 matches
Mail list logo
