If I understand it correctly ... then use the shared_clone( $dbh ) ... Is that even remotely correct?

No. Look again and you'll see that I don't use the share_clone( $dbh ) at all within the threads. I never actually access the second parameter I pass:

my @threads = map threads->create( \&thread, $Q, shared_clone( $dbh ) 
+), 1 .. $T;
#............................................^1, ^^^^^^^^^ 2 ^^^^^^^^
[download]

within the thread procedures;

sub thread {
     my $tid = threads->tid;
     my( $Q ) = @_;
[download]

I'm afraid that this is a 'left-over' -- ie. I should have deleted it before posting; sorry -- from earlier experiments that lead to my discovering the need for the workaround.

The reason we need a workaround is because sqlite :memory: dbs are only visible to the connection that creates them.

But if you share a $dbi, the contents of the dbi (the C/XS bits that the sqlite libraries use) gets mangled internally by DBI such that those libraries see the shared connection from different threads as being different connections; thus the threads see different :memory: dbs.

The workaround is to use the uri-form of the connect string + the modifiers mode=memory&cache=shared to cause sqlite to connect all the (new; unshared) connects made in each of the threads to the same db.

Why do the shared_clone( $dbh )? Isn't the shared memdb enough for the threads to have access to the same memory?

Not applicable :)

What's the purpose of the $Q->nq( ('Wakey wakey') x $T ); ... $Q->dq; ## Wait for DB ?

Why pass the string to the thread and then just dequeue it? And what's the relation to waiting for DB?

Again, this is a left-over from earlier experiments. Its purpose was to block the threads whilst I created the db in the main code as originally I was creating the threads before I created the db. The idea was to prevent the memory used by the DB being cloned when the threads are created.

However, as I'm no longer using a shared connection handle, that precaution is no longer relevant. So, the nqing of the strings and the associated dqing of them can be safely removed.

Here's the latest for of the code with a few tweaks and some timing code added:

Finally, I've still to resolve the undeleted file problem. The fact that a file is being created at all is somewhat disconcerting as it mean that I'm not getting the (purely) memory db I was hoping for; and could mean that performance isn't what it should be as a result. I did try contacting the mailing list about this, but got no useful response. I haven't had time/motivation to pursue it further.