Re: Locked threads and tcp timeouts

How can i break execution of that thread? Sending signals won't work since they are processed only after the blocking operation is completed. Is that even possible?

You might try the following, and if that dosn't work, because of the needed SIGINT, the only sure fire way I know would be to fork off the code that can block, run a timer on it, and kill -9 it's $pid when the timer expires.

#!/usr/bin/perl -w
use strict;
use threads;
use threads::shared;

my $timer_go:shared = 0;

my $worker = threads->create(\&worker);
my $timer = threads->create(\&timer,$worker)->detach();

print "hit enter to start\n";
<>;
$timer_go=1;


while( (scalar threads->list) > 0   ){
 print scalar threads->list,"\n"; 
 sleep 1;
foreach my $thread (threads->list) {
   if( $thread->is_joinable ){ $thread->join;}
   }
}

print "worker joined, all done\n";
exit;


sub timer {
  my $worker = shift;
   while(1){     
       if($timer_go){
        my $count = 0;
             while(1){ 
                  $count++;
                  if($count > 5){    
                         print "timed out\n";
                          # Send a signal to a thread
                         $worker->kill('INT');
                         return; # will destroy a detached thread
                        } 
                  sleep 1;
                  print "timing $count\n";
            }
       }else{sleep 1}
    }
}

sub worker {
       $|++;
       $SIG{INT} = sub{ warn "Caught Zap!\n"; threads->exit() };
       # threads->exit() will exit thread only

      while(1){sleep 1;  next}

      return;
}
[download]

I'm not really a human, but I play one on earth.
Old Perl Programmer Haiku ................... flash japh

Comment on Re: Locked threads and tcp timeouts Download Code

Replies are listed 'Best First'.
Re^2: Locked threads and tcp timeouts by BrowserUk (Patriarch) on Feb 16, 2012 at 17:05 UTC
This will not work if the thread is in a blocking IO read state. Ie. The OPs problem.	[reply]
Re^3: Locked threads and tcp timeouts by nikosv (Deacon) on Feb 19, 2012 at 15:42 UTC
would a more drastic approach work ? like getting the underlying Win32 handle ($thr->_handle()) of the worker thread (since threads in Windows are created with CreateThread after all), and kill the thread by passing the handle to the TerminateThread api call ? a note to the OP, when killing threads associated with calls to the dbms i.e sql execution, might lead to locked resources i.e tables or rows since there is no proper clean up	[reply]
Re^4: Locked threads and tcp timeouts by BrowserUk (Patriarch) on Feb 20, 2012 at 02:50 UTC
There are two problems with the idea. I've never managed to work out how to use the value returned from _handle(). It appears to be returned in the IV slot of the SV: `SV = IV(0x3afb470) at 0x3afb478 REFCNT = 1 FLAGS = (PADMY,IOK,pIOK) IV = 94514760` [download] but all my attempts to use it from XS in calls to the OS result in `The handle is invalid`. Terminating threads is a desperate measure as it does not allow either the thread itself, the OS, or Perl to clean up after themselves, leading to a massive memory leak. Not to mention the potential for all sorts of nasties with dangling pointers etc. If you bypass the first problem by calling an XS sub that gets the current thread handle from the OS -- which isn't very useful as it can only be called from within the thread to be killed -- and run a loop that creates threads and has them self terminate, then you see the scope of the massive memory leak it creates: `#! perl -slw use strict; use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => 'TerminateThreadTest', CLEAN_AFTER +_BUILD => 0; int killThread( SV t, SV ec ) { printf( "t:%p ec:%d\n", SvIV( t ), SvIV( ec ) ); return TerminateThread( SvIV( t ), SvIV( ec ) ); } void hariKari( SV *exitCode ) { TerminateThread( GetCurrentThread(), SvIV( exitCode ) ); } END_C use Devel::Peek; use threads; for( 1 .. 100 ) { my $t = async { sleep 5; hariKari( 12345 ); }; sleep 10; }` [download] On my system, the above script leaks around 2MB for every thread killed. Whilst that could be reduce by spawning early and trimming the stack etc., it will never be zero. 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. The start of some sanity?	[reply] [d/l] [select]