Hmmm... that's odd. I found that the close STDIN did the job perfectly. I note you are using ActiveState perl v5.8.8 on a dual core machine -- while I have 5.10.0, single core... but have no way of knowing whether either accounts for the difference.

Just in case: it's not necessary to have the sleep in the input thread and the close together... the close on its own does the trick (here).

I wondered whether it made a difference if the input thread was blocked on the <STDIN> at the time the main thread did the close STDIN in the main thread to block or fail... which would be more likely on a dual core machine. However, I tried a threads->yield() before the close, and that didn't make any difference. (The input loop was definitely waiting for <STDIN> but the close completed successfully.)I suppose this could be different on 5.8.8 ?

If you wanted to play with semaphores you could do:

# Create terminal watcher

print "Create terminal watcher...\n";

my $Q_stdin = Thread::Queue->new ;
my $S_stdin = Thread::Semaphore->new(0) ;

print "fileno(STDIN) = ", fileno(STDIN), "\n" ;

async {
  $S_stdin->down() ;
  print "Reading STDIN, fileno=", fileno(STDIN), "\n" ;
  while (defined( $_ = <STDIN> )) {
    chomp ;
    print "\n+IN : '$_'   " ;
    $Q_stdin->enqueue( $_ ) ;
    print "*" ;
  } ;

}->detach;

close STDIN ;                          ### no longer our business     
+  <<<<
print "STDIN is: ", defined(fileno(STDIN)) ? 'open' : 'closed', "\n" ;

$S_stdin->up() ;
[download]

which guarantees that the main thread has closed STDIN before the input thread touches it.