Yes, once a thread has blocked on a recv waiting for something from the far end, you are stuck. With a TCP connection, if the far end simply stops talking to you, recv will wait for a very long time indeed. With UDP there is no connection to close even.

Thread::Queue has no mechanism for interrupting recv.

I think the simplest way to tackle this is to implement a time-out on recv. I would recommend using IO::Select for this (see recent thread). Now you can both time-out dead connections and periodically look for messages from the mother-ship.

If you want the thread to respond instantly to a message from the mother-ship, then you have a rather harder problem. You could replace your Thread::Queue by an intra-machine socket connection (or use such a connection to signal that data is available). Now in your thread you need to use IO::Select on both sockets. This does appear to be overkill ! (I'd have to be very sure that a simple time-out really wasn't acceptable...)

Sadly, thread signalling does not interrupt I/O operations... so no help from that quarter.

If all you want to do is to terminate the thread and its connection, you could shutdown the connection.