Clear questions and runnable code
get the best and fastest answer
Re: IO::Socket::INET in worker threadsby gone2015 (Deacon)
|on Feb 14, 2009 at 14:28 UTC
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.