Tk is not thread safe. I'm not sure that any kind of process that uses threads and Tk will "get along".

It looks like to me that you are executing thread code from a Tk button:

$button = $mw->Button(
      -text => 'Stop thread',
       -command => sub{
        $button->configure(-state=>'disabled');
        $die = 1;
       $thr->join;
      },
     )->pack();
[download]

It has been years since I thought using Tk as the display for distributed client processes connected to a central DB server process. I never implemented the code - but did investigate some possibilities. I think your process that runs Tk cannot have any threads in it at all. If such a thing is possible, I'd also like to hear about it! In my architecture, the central DB server process would not have had any UI. Clients would connect and send/display stuff from the central DB process. With Tk, you have to be mindful not to have any blocking I/O in the Tk process- otherwise the GUI will hang and become unresponsive. I seem to remember that there is way to schedule a periodic fast executing task from within Tk. This is sufficient to manage a TCP connection, but you have to test if the socket has data waiting to be read before reading it (can't wait indefinitely).

I seem to remember that on Windows, Perl does a fork emulation using threads. How that would affect Tk is unknown to me. In my abandoned project, The central process would have run on Unix with traditional forking to a separate process for each connection. Each client would have been a single process running Tk on a Windows machine. I don't know if you will be forced into a connection server running threads and the Tk GUI in a separate process or not? That could be true if the threads have to do any significant amount of work.