Non-blocking IO and threads

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

I am trying to utilize threads and non-blocking IO but have run into a stumbling block. I have a separate thread monitoring STDIN via Term::Readkey. After some time I create another thread to do non-related processing but this thread hangs at creation time until something happens (i.e. a key is pressed) in the first thread (read_in). Am I creating threads incorrectly or is there something else blocking the proc_it thread below? Code was modified from a nonblocking IO post by zentara. This code will hang at count = 10 until something is read from the command prompt. How do I avoid this block?

#!/usr/bin/perl
use warnings;
use strict;
use Term::ReadKey;
use threads;

$|++;
ReadMode('cbreak');

# works non-blocking if read stdin is in a thread
my $count = 0;
my $thr = threads->new(\&read_in)->detach;

while(1){
  print "test, count:$count\n";
  sleep 1;
  if ($count == 10) {
    my $thr_proc = threads->new(\&proc_it)->detach;
  }
  $count++;
}

ReadMode('normal'); # restore normal tty settings


sub proc_it{
  while(1) {
    print "@";
    sleep 2;
  }
}


sub read_in{
  while(1){
    my $char;
      if (defined ($char = ReadKey(0)) ) {
        print "\t\t$char->", ord($char),"\n";    
        if($char eq 'q'){exit}
      }
  }
}

__END__
[download]

Comment on Non-blocking IO and threads Download Code

Replies are listed 'Best First'.
Re: Non-blocking IO and threads by runrig (Abbot) on Oct 06, 2011 at 19:00 UTC
FWIW, I do not get the hang if I put a `close STDIN;` in the first while loop, and the rest still seems to work: `while (1) { close STDIN; ... }` [download] Duh, I guess that should also work if the close is before the while loop...(update: yep, it does): `close STDIN; while (1) { ... }` [download]	[reply] [d/l] [select]
Re^2: Non-blocking IO and threads by PhillyR (Acolyte) on Oct 06, 2011 at 19:38 UTC
This worked for me! Thank you. My proxy server now has the ability to shut down from the command prompt.	[reply]
Re: Non-blocking IO and threads by BrowserUk (Patriarch) on Oct 06, 2011 at 17:11 UTC
This code will hang at count = 10 until something is read from the command prompt. How do I avoid this block? That isn't what happens running your code on my system. I waited until the count reached 14 the typed 'x' 3 times and ^C once: `c:\test>junk85 test, count:0 test, count:1 test, count:2 test, count:3 test, count:4 test, count:5 test, count:6 test, count:7 test, count:8 test, count:9 test, count:10 test, count:11 @test, count:12 @test, count:13 test, count:14 x->120 @test, count:15 x->120 test, count:16 x->120 @test, count:17 Terminating on signal SIGINT(2)` [download] Hard to advise on how to avoid something that doesn't happen? 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.	[reply] [d/l]
Re^2: Non-blocking IO and threads by PhillyR (Acolyte) on Oct 06, 2011 at 18:03 UTC
What if I tell you I'm using ActiveState 5.8 on a Windows machine?	[reply]
Re^3: Non-blocking IO and threads by BrowserUk (Patriarch) on Oct 06, 2011 at 18:36 UTC
I'm using ActiveState 5.8 on a Windows machine? I used AS 5.10.1 on Windows above. I just tried it with AS 5.8.9 and it blocks as you describe. I do not have an explanation for that, but the work-around is obvious. Upgrade. 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.	[reply]
Re^3: Non-blocking IO and threads by clueless newbie (Curate) on Oct 06, 2011 at 18:32 UTC
I, too, am seeing a "hang" at "test, count:10" (under Activestate 5.12.4/Windows XP). And I must note that I'm not seeing that "hang" under Ubuntu-"Natty Narwhal".	[reply]
Re: Non-blocking IO and threads by Anonymous Monk on Oct 11, 2011 at 05:32 UTC
IIRC, "the terminal is special." It's pretty much always going to be buffered, for both input and output. The days of a real TTY hooked to a serial port are (mostly) long gone now. Terminal I/O is multiplexed through a windowing system.	[reply]