I think you'll have better luck if you only load DBI in the child.

my $pid = fork();
if (not defined $pid) {
   # Fork error
   ...
}
elsif (not $pid) {
   # Child process
   require DBI;  # Not "use" to load in child only.
   ...
}
else {
   # Parent process
   ...
}
[download]

This is based on a vague memory of something I once read. I hope it works.

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.

As far as I could tell from quick glances, there has been a lot of recent p5p activity by jdhedden and others around threads. Would people in the know care to discuss what kinds of improvement we may expect on the threads front with 5.10, please? This may also be a good opportunity for Parrot developers to update us on the state of Parrot threads and developments since Parrot, threads & fears for the future.. Cheers.

The problems with Perl 5 threads are not due to the developers being incompetent nor for lack of effort. Any improvements to the Perl 5 threading model are going to be small improvements because the big problems are fundamental. You can't just take a monolithic system like Perl 5 and throw threads into the design as an after-thought. And Perl 5, unluckily, is an especially good example of a system that strongly resists the addition of good threading.

At this point, I suspect that you'd often get better performance on Unix Perl if threading was implemented using fork with IPC used for sharing variables (especially if mmap were used). That is how fundamentally unlike threads the current Perl 5 threading model has become after years of trying and failing to make Perl work with a more thread-like model.

- tye        

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'm not too sure about windows, but DBI / DBD::mysql on linux with threads works fine, for certain values of fine:

You can't share handles over multiple thread. You should probably not use a handle that's in scope from the parent thread either. Every thread should have its own database handle(s), so create new connections at the start of a thread if you need them.

You need to compile DBD::mysql with thread support. AFAIK most default builds are done without thread support even on systems that have a threaded perl.

On my (linux) system, that means running mysql_config  --libs_r and passing the output of that to Makefile.PL prior to compilation:

$ mysql_config --libs_r
-L/usr/lib/mysql -lmysqlclient_r
$ perl Makefile.PL --libs "-L/usr/lib/mysql -lmysqlclient_r"
[download]

PS: starting a new thread in perl is slow. You might not want to do it for each event. Having a pool of threads is probably more efficient.

Your threads documentation is out of date. See also my reply below.
"What should it profit a man, if he should win a flame war, yet lose his cool?"