Unsticking a thread

chrism01 has asked for the wisdom of the Perl Monks concerning the following question:

Hi,
I'm writing a threaded app, that eventually gets stuck on a particulay fn call, specifically

Radius->newRecvFrom($sckt,$dict);

which is from the Radiator Radius app.

Not only does the individual thread get stuck, but the whole prog (ie all threads) seems to hang when the first one does.
Is there a way of unsticking it or timing out somehow?
Also, why does the whole prog stick, not just the individual thread?
Just to be clear, if I need to put the fn in it's own thread and then have to kill the fn (which is fine), I only want to have to kill the stuck thread, not any other threads/the whole prog, as it's a daemon that is supposed to run 24/7.

cheers
Chris

Comment on Unsticking a thread

Replies are listed 'Best First'.
Re: Unsticking a thread by BrowserUk (Patriarch) on Dec 10, 2004 at 05:33 UTC
Without sight of the whole program, this is impossible to answer. Any speculations would be, exactly that: speculation. Along with posting your script (preferably cut down to the minimum that demonstrates the error), you will also need to give a few details of your environment. Which version of perl? What OS/version? What dependancies/versions? A few preemptive strikes are possible. If you're using pThreads--don't. If you're using iThreads and a version of perl earlier than 5.8.4--upgrade. If you're sharing objects between threads--stop! I'll try to be more helpful once you supply some more information. For the record, the iThreads API does not provide for any mechanism for killing threads. It is possible, with caveats, to do this under Win32. I am not aware of a mechanism for doing under other OSs, though that's isn't saying much, as I am very unfamiliar with other OSs :) Examine what is said, not who speaks. The end of an era! "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen "Think for yourself!" - Abigail "Time is a poor substitute for thought"--theorbtwo "Efficiency is intelligent laziness." -David Dunham "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply]
Re^2: Unsticking a thread by chrism01 (Friar) on Dec 10, 2004 at 05:47 UTC
Thx for the fast response. Here are some answers to your request: perl -v This is perl, v5.8.5 built for i386-linux-thread-multi uname -a Linux 2.6.9-1.681_FC3smp #1 SMP Thu Nov 18 15:19:10 EST 2004 i686 i686 i386 GNU/Linux Radiator is v3.9 I'm sharing some scalars and hashes, but no Perl 'objects'. I'll try to provide a cut down version if possible (actual is 5113 lines), but I'm not sure how repeatable it is ... HTH Chris	[reply]
Re: Unsticking a thread by conrad (Beadle) on Dec 10, 2004 at 11:13 UTC
What is the nature of the hang? Is it using CPU at all while waiting? Is this “Radius” package thread-safe? If all your threads lock up, that strongly suggests to me that you're sharing something that you shouldn't: if you're using Radius objects (or maybe some other class) from another thread you may well find that the package isn't thread-safe. If you're sure it is thread-safe then check whether you're sharing something inappropriate — could you have more than one thread trying to read from that socket, for example? It is possible to use non-thread-safe modules in threaded applications, but generally you have to confine your use of the module to a single thread in order to get away with it. Occasionally you can hack it by creating a lock outside the module and using that to serialise access to the module. A little more contextual detail would help…	[reply]