Re: Diagnosing blocking io (or: finding the WHY of my Open2 woes).

My suspicion is (though I haven't verified (because I don't have 'js' here)) that the subprocess (js) is using block buffering for its output when being run non-interactively... in which case your readline might hang waiting for an end-of-line.

Unless you have control over the source of the subprocess to change such buffering behaviour, you're essentially out of luck.

Comment on Re: Diagnosing blocking io (or: finding the WHY of my Open2 woes). Select or Download Code

Replies are listed 'Best First'.
Re^2: Diagnosing blocking io (or: finding the WHY of my Open2 woes). by Fletch (Bishop) on Nov 18, 2008 at 22:44 UTC
If this is the case you may be able to trick it by using Expect or IPC::Run to run it on a pty so that it thinks it's being run interactively. The cake is a lie. The cake is a lie. The cake is a lie.	[reply]
Re^3: Diagnosing blocking io (or: finding the WHY of my Open2 woes). by Socrates (Acolyte) on Nov 18, 2008 at 22:50 UTC
I'd thought of both of these, but I was curious as to whether there was any way to do it without requiring non-core modules.	[reply]
Re^2: Diagnosing blocking io (or: finding the WHY of my Open2 woes). by Socrates (Acolyte) on Nov 18, 2008 at 22:49 UTC
Sure, and if I'm out of luck, that's fine, but I'm also trying to increase my understanding here, so would there be any way to go about verifying that it's using block buffering? Also, aren't I sending it an end-of-line by using the newline character at the end of each print? As I said, it works if I don't enter the readline() loop via Javascript. I can issue other javascript commands perfectly fine.	[reply]
Re^3: Diagnosing blocking io (or: finding the WHY of my Open2 woes). by almut (Canon) on Nov 18, 2008 at 22:54 UTC
Actually, on second thought, your problem might rather be that the subprocess' output buffer is filling up... so it stops processing anything (i.e. hangs/waits) before you get a chance to read/emtpy the buffer (as you're doing the reading after the writing). Just another hypothesis, though :) How much output would you expect when things don't work? As to diagnosing what's going on, `strace` would probably be a good tool.	[reply] [d/l]
Re^4: Diagnosing blocking io (or: finding the WHY of my Open2 woes). by Socrates (Acolyte) on Nov 18, 2008 at 22:57 UTC
I don't think that's the problem. The expected output from the test case is simply "No problems reported."	[reply]
Re^2: Diagnosing blocking io (or: finding the WHY of my Open2 woes). (fix libc) by tye (Sage) on Nov 19, 2008 at 01:11 UTC
...and this has been an obvious problem for decades in Unix, and yet there is still no libc that allows a simple environment variable to influence the buffering mode used for stdout... - tye	[reply]