Assuming you're actually using threads, be advised that threading with the DBI is a bit hit or miss. It requires (a) a thread-safe database driver and (b) a threads-aware DBI driver.

I believe DBD::MySQL is one of the few (only ?) DBD's which have implemented the internal brain surgery needed to swap things between threads, and I think your app has to do some extra work to enable it.

Attempting to recover a database connection across a fork() (regardless the platform or API) can be a dangerous operation (as you've discovered), due to the complex interactions most database drivers have with their connection to the database. So, as ikegami pointed out, you'll need to create your connection within the child process. And in most instances, this also applies to Perl threads. Oh, BTW, on Windows, fork() is threads, but probably less stable than regular threads.

I'll toss in DBIx::Threaded as another option. It uses apartment threading to isolate the connection in its own thread, and distributes proxies to other threads for access. Essentially, its a poor man' Actor model. However, as it currently relies on threads::shared, performance in contentious systems is less than ideal.

As to other comments wrt threads here, I'll suggest that the more recent releases of threads and threads::shared permit reducing thread footprint, add add'l functionality, and improve stability (many thnx to jdhedden's efforts). However, ithreads still suffers from lengthy startup times and large memory footprints. I'll offer the following advice:

• create thread pools early before you've loaded a bunch of modules
• consider a shared nothing Actor model as much as possible

I'll offer Thread::Apartment as a means to accomplish the latter.