First, if you haven't already, please produce a simple testcase demonstrating the failure and raise a bug report against threads. If the testcase demonstrates the problem with the latest cpan version of that module in conjunction with 5.10 so much the greater chance of getting some action on it.

Next a few possibilities.

• If your threading design uses a pool approach and you can afford to leave your threads dormant after they finished their useful lives, then neither detach nor join them, but let lie fallow until the GUI is closed.

  Then use POSIX::_exit to bypass the global destruction phase and your code will end cleanly (and more quickly).

• If that's not acceptable, then separate the GUI from the threaded code.

  Have the gui run as a separate script that starts the threaded code via piped open

  use GTK2;
  ...
  my $pid = open my $kid, "threadScript |"  or die $!;
  ...
  [download]

  The kid can provide trace output to its stdout and the GUI can use the GTK2 equivalent of Tk::Fileevent to track and display that status.

• Revert to 5.8.6 and the version of threads that was distributed with it. It was possible, though it required care, to make GTK2 and threads coexist with that combination. The secret was in ensuring that all your non-GTK2 threads were spawned before you require'd (not use'd), any GTK modules.

  Unfortunately, despite all the good stuff the dual-lifing of threads has brought, the correction of this type of memory pool management problem that used to be routinely tracked down and corrected by the wizards on p5p, is now attributed to the threads module and so tends to slip under the radar of those experts.

For more useful help than this, you would need to post some code showing what you are doing.