yes, thanks. fork() duplicating all handles, will create a mess and on top of that, it will try to close all duplicated handles on exit of child (with commits or rollbacks etc) even if child has not opened any itself! This last will be a hard nut to debug.

The only thing it remains foggy, to me, is how testing should go with fork. To start with, test numbers are mixed and Test::More is randomly confused and fails. Using Test::Fork fixes that but with loosing test numbers which takes me to the real problem: I have to ensure a sequence. First the child opens the DB and locks it, *next* the parent opens the same DB and checks if it's locked and does whatever it has to do on it. That's why I have a sleep() just as the parent starts, to give time to child to lock the DB. But that's not guaranteed at all, although chances are miniscule.

I believe/read that single SQLite DB is ok being accessed concurrently by many processes.

Update: in a sort of rubber-ducking-way, I guess I don't need a fork at all!

Just open the DB first and lock it, don't close it. Next (and sequentially), open the same DB and check if it's locked etc. At the end close both connections to the same DB. BTW my test case is to be able to just read the DB when it is locked, nothing fancy more than read. The real situation is Firefox locking aggressively its cookies SQLite db and I can not read the current cookies when FF is running.