There is an expected but never before observed bug to do with locking
and threads.

ORLite in default mode runs every SQL statement as a separate
connection. The connectionless nature means we don't have to care
about the problem of DBI being incompatible with threads.

Unfortunately, now we have this great locking system.

And the locking system is going to run persistant connections to the
database, which might end up surviving across the thread fork, and
thus exploding in the manner you see.

Because Padre only uses transactions as a convenience to speed up
statements and control when the disk blocking will occur, we can use
the following solution.

1. Make the Task Manager aware that the locking system exists.

2. Add special code to the lock manager so that when the Task Manager
is about to fork off a thread, any current database connection is
committed, and then disconnected.

3. After the thread is spawned, the Task Manager should return the DB
lock to the state it was before the thread spawn (either connected, or
not connected).

4. The above should have very very tight so there's no chance for
anything other than the thread spawn to occur (other code might screw
up the lock state).

5. The database operations should occur WITHOUT changing the
underlying state (lock counts etc) of the locking system.

Adam K

Adam K

On 9 February 2010 21:01, Peter Lavender <[email protected]> wrote:
> Hi Everyone,
>
> Just in case someone knows, this was from trunk -r10635 tonight:
>
> p...@owl~/Programming/Perl/padre/trunk/Padre $ ./dev.pl -a
>     DESTROY ignored because DBI dbh handle (DBD::SQLite::db) is owned by
> thread 863c008 not current thread b3435c0
>     DESTROY ignored because DBI dbh handle (DBD::SQLite::db) is owned by
> thread 863c008 not current thread bed8410
>     DESTROY ignored because DBI dbh handle (DBD::SQLite::db) is owned by
> thread 863c008 not current thread 9a52490
>
>
> I closed Padre normally and saw this in the console.
>
> Pete.
>
>
>
> _______________________________________________
> Padre-dev mailing list
> [email protected]
> http://mail.perlide.org/mailman/listinfo/padre-dev
>
>
_______________________________________________
Padre-dev mailing list
[email protected]
http://mail.perlide.org/mailman/listinfo/padre-dev

Reply via email to