@lparList is tested with 1 and 2 elements. (elements can be 1 lpar or a , seperated list of lpars, stored in @LPARs of the thread) Both times the signal arrives, the code that has to be executed by the thread when the signal is received is executed. However, the last command (threads->exit() or the other options) are executed, but don't result in the end of the thread.

The 'do stuff' is a large block of code used to gather all info I need to send a command via ssh (Net::OpenSSH) to a server, which then stops the machine. After the command is issued, the script checks every 30 seconds if the system is already dead. When it's dead, it continues to the next entry of @LPARs (in the test 1 thread with 1 @LPARs element, 1 thread with 2 @LPARs elements)

The behaviour I see is that the timeout is reached, the signal ALRM is send to the 1st thread that's still running, it's acted upon (i.e. I get all expected output of the function triggered with the signal), including the call of return/die/threads->exit(), but it just simply doesn't die.

The best suggestion I can come up with given a) your need to stay with 5.8.8; and b) the still scant information of what the threads are doing; is:

1. discard all the signaling stuff; it isn't doing you any good anyway.
2. detach the threads as you create them.
3. Have your main thread sleep for the timeout period and then just fall off the end of the script.

   When the main thread ends; all the others will end also.

   foreach $lpar ( @lparList ) { 
       threads->create( 
           sub { 
               threads->yield(); 
               manageLPAR ($action,$lpar); 
           }
       )->detach; 
   }
   
   sleep $timeout;
   
   ## fall of the end of the script
   ## the detach threads will end when the main thread does.
   [download]

   I rarely advocate abandoning threads this way; but since even if the signals 'worked', you would have no possibility for cleanup as you could never know what your code was doing when the signal to exit arrived; it makes no difference in this case.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

This is an option, but then I can better al together abandon threads. The work that's done in this thread has to end before I can execute the fallback option.

This function askes the virtual system to die, the friendly way, via the management server. When it's not dead in the allotted timeframe, the command has to be killed so I can issue the unfriendly command to turn the system off. (i.e. pull the virtual plug) The system (hatrdware the virtual machine is running on) won't accept a second command for the virtual system when there is still a command being processed.

I was looking at threads to solve this issue with a neat single script, to replace the bunch of KSH scripts I now have and that are to slow, but as it seems this is not possible. (with this old perl/threads module) To bad.

Another thought. You say in your OP: "the 5.8.8 version doesn't support threads->exit().". You also say you have similar code working elsewhere.

threads is a cpan module. Why not simply upgrade to a newer version of that module that does support threads->exit?

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

That one is easy, I have no accepted build environment for the module. (at least, that's hat the module reports on the AIX 6.1 system I have available) The Net:OpenSSH module accepts the available gcc, threads doesn't.