Re: IO::Select woes

I think the can_read()'s timeout, which is the same for both executions in the pipeline, is the culprit. Perhaps you could add a switch for the user to tell the script that it is either in read or write mode?

Edit: what I mean is that both scripts in the pipeline upon execution wait for at most 0.5s for piped input. That stops the 1st script from outputting anything to be passed to the 2nd script. They are run one after the other with a tiny time difference. Will this difference be enough for the 1st script to output and the 2nd to still be blocked in the can_read()? To see that, clone your test.pl and run the 1st with smaller timeout than the 2nd. Re: debugger, I can not explain what you experience. But I am sure that in this particular case, loading different libraries is not relevant.

I can't resist offering this halfway measure (don't take it seriously hehe): use a random timeout (can_read(rand)). In this way your pipeline will work correctly half the time, on average (given only 2 items in the pipeline). Correction edit: can_read(0.5+rand)

If you are a die-hard "do-what-i-mean" perl hacker and insist on not using CLI switches, then here is a tip: in the pipeline perl test.pl | perl test.pl, pid of 1st script (left, from where I see it) < pid of 2nd script (right). (print "my pid is $$\n:";)

1min Edit: Oh, I just remembered that in linux there is the -t test to check if your STDIN is associated with a terminal (your 1st script in the pipeline is, the second is associated with the output of the 1st script). And yes, just checked that in Perl you can do: if( -t STDIN ){ print "$$: not piped\n" } else { print "$$: piped\n" }.

And by the way, IO:Select's doc states also how to use the handle(s) which can_read() returns as ready for reading, and that's the handles you should use (instead of using raw "STDIN").

bw, bliako

Comment on Re: IO::Select woes Select or Download Code

Replies are listed 'Best First'.
Re^2: IO::Select woes by cavac (Prior) on May 05, 2023 at 07:27 UTC
I can't resist offering this halfway measure (don't take it seriously hehe): use a random timeout (can_read(rand)). Random (or rather "slightly randomized") timeouts and/or sleeps can be quite useful when you have a lot of cyclic process forked from the same parent process to spread the workload more evenly over time (as long as you remember to call srand after forking). It's also extremely useful in finding bugs, because it helps simulate the messiness of production environment (compared to the relatively clean one-process-at-a-time developer systems). PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP	[reply]
Re^2: IO::Select woes by Anonymous Monk on May 05, 2023 at 19:26 UTC
Thank you thank you !! It took me a day to absorb your post, but it is absolutely genius! Your comments are very insightful... and I believe you are absolutely correct about the randomization. It seems to work now, but as you say, only about half the time !! I don't understand what's going on here at all! `## first run with added randomization pid 46234 NOT piped pid 46234 checking pipe pid 46235 piped pid 46235 checking pipe pid 46235 cannot read ## 2nd run with added randomization pid 46327 NOT piped pid 46327 checking pipe pid 46328 piped pid 46328 checking pipe pid 46327 cannot read reading from pipe data <= IT CAN READ pid 46328 can read` [download]	[reply] [d/l]