Using Perl on Win32 I would avoid threads (Perl sucks at threads¹) and avoid fork (fork is emulated by Win32 Perl and only somewhat successfully and this emulation also uses Perl threads, which suck, in case I didn't just mention that). (:

As ikegami notes, if you do use threads (via fork or otherwise), be sure to connect to the DB from the child. Perl threads create a new instance of the Perl interpretter and simple scalar values get copied fine but things with operating system magic attached (like file handles such as network connections to a database) can't be copied as easily. And the module isn't written to expect a single connection to be copied and used by two instances at once. So connecting and then forking or creating a new Perl thread will usually not work.

But because you are using both Perl and Win32, I'd instead spawn a DB client and feed tasks to it. That is, have either a separate Perl script or just a separate way of invoking the same Perl script and then invoke that in a child process and when an event happens, hand off the time-consuming task to it.

This can sometimes be handled by something as simple as:

    use IO::Handle;
    open DBCHILD, "| $^X $0 -dbchild" or die ...;
    DBCHILD->autoflush( 1 );
    # ...
    sub eventHandler {
        # ...
        print DBCHILD $eventTaskDesc, $/;
    }
[download]

Then the DB child just reads STDIN for things that it should do.

¹ The reason good threads are nice is that they are more efficient in memory than fork, share everything implicitly (which is also why they are not for the unprepared as preventing race conditions due to all this sharing requires a significant investment in tools and techniques), and share very efficiently. Perl threads, however, are less memory efficient than regular fork, share almost nothing implicitly, and don't even share efficiently.