I ended up going with the separate script which handles the threads and copies. It works great!

Glad to have helped. Perhaps you could return the favour.

Did you produce a minimal testcase that demonstrated the problem and raise a bug report against threads? If not, could you please do so, because it won't get fixed unless they know the problem exists.

Late addition

I just went looking for the GTK equivalent of Tk::fileevent and noticed something that I don't recall seeing before. Maybe you missed it too? In the pod for the top-level GTK2 package which is generally just an index to the rest of the documentation, so you may well have skipped over it, there is this:

use Gtk2 qw/-init -threads-init/;
[download]

-threads-init

Equivalent to Gtk2::Gdk::Threads->init, called to initialze/enable gdk's thread safety mechanisms so that gdk can be accessed from multiple threads when used in conjunction with Gtk2::Gdk::Threads->enter and Gtk2::Gdk::Threads->leave. If invoked as Gtk2::Gdk::Threads->init it should be done before Gtk2->init is called, if done by "use Gtk2 -init -threads-init" order does not matter.

Which kinda sounds like it might be a solution to your original problem? Now you may be happy with your current route, but if you haven't already seen and tried this option, then it might be as well to, before raising the bug-report I encouraged you to do.

I'd try this myself, but I remember installing GTK2 was non-trivial the last time I did it, and I then broke my Perl/GTK2 bindings by installing OCaml/GTK2 bindings. Since I don't use Perl/GTK2 for anything, I've never got around to trying fixing it, and don't really have the motivation to go through the pain again.

Anyway, if you've tried it and it didn't help, please raise the bug-report. If you try it now and it fixes your problem, then a) it gives you choices; b) please report back here so that anyone coming along later can see the solution.

End of late addition

Now I just need to finish getting the IPC::Open2 stuff working so I can retrieve the success/failure results back from the copy processes, umount the drives, notify the user, etc.

Do you need bi-directional comms after the child processes are running? Or just to pass some startup information on the spawn and retrieve status/results?

If you can get away with the latter, then passing the startup info as command line arguments and retrieving ongoing status and results from stdout using a simple piped open

push @kidPids, open $IOkids[ @IOkids ], qq[ theKidScript arg1 arg2 arg
+3 |] or die ...;
...## Give the filehandle to GTKs equivalent of Tks fileevent api
[download]

Might be easier than IPC::Open2 which I've had problems with in the past.