I'm writing a Java object that runs a Perl script. I use the Process
object to do this. I set everything up, then call the waitFor() method
- and the Java program hangs. I've put debug logging into both the
Perl script and the java program, so I see that the Perl script runs
all the way through, but the last thing the Java program does is
execute waitFor().

-- 
Tim Slattery
Slattery_T@bls.gov
http://members.cox.net/slatteryt

On Mon, 20 Dec 2010, Tim Slattery wrote:

> I'm writing a Java object that runs a Perl script. I use the Process 
> object to do this. I set everything up, then call the waitFor() method - 
> and the Java program hangs. I've put debug logging into both the Perl 
> script and the java program, so I see that the Perl script runs all the 
> way through, but the last thing the Java program does is execute 
> waitFor().

The most common bug around this sort of thing is that the parent process 
doesn't read all the child's output from its standard output stream. The 
buffer for the pipe between the two fills up, and the child then gets 
blocked waiting for it to empty so that it can finish writing, which of 
course never happens because the parent is waiting for the child to 
terminate. Deadlock ensues.

However, from what you say, it sounds like the Perl script is terminating. 
Is that definitely the case? Could it be that the script finishes running, 
but the buffer is never drained, so the Perl interpreter doesn't exit? Can 
you see the interpreter in a process listing after the script seems to 
have finished? If you drain all the output from the child, does that help?

If not, i'm not sure what to suggest. I note that the javadoc for Process 
does mention that:

  The methods that create processes may not work well for special processes
  on certain native platforms, such as native windowing processes, daemon
  processes, Win16/DOS processes on Microsoft Windows, or shell scripts.

So if a Perl script is like a shell script (and it is - albeit a hideously 
deformed shell script with mutant superpowers), there could be trouble. 
That sounds more like arse-covering than a genuine warning, though.

tom

-- 
Damn the Solar System. Bad light; planets too distant; pestered with
comets; feeble contrivance; could make a better myself. -- Francis Jeffery

On Mon, 20 Dec 2010 12:51:24 -0500, Tim Slattery <Slattery_T@bls.gov>
wrote, quoted or indirectly quoted someone who said :

>I'm writing a Java object that runs a Perl script. I use the Process
>object to do this. I set everything up, then call the waitFor() method
>- and the Java program hangs. I've put debug logging into both the
>Perl script and the java program, so I see that the Perl script runs
>all the way through, but the last thing the Java program does is
>execute waitFor().

see http://mindprod.com/jgloss/exec.html
for the usual pitfalls. If your script is eating or producing chars
you need threads to deal with them.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
A short order cook is a master of multitasking. Every movement is 
optimised from years of practice. Yet when a computer executes a
multitasking program, it approaches the task as if for the first time.

Tom Anderson <twic@urchin.earth.li> wrote:

>On Mon, 20 Dec 2010, Tim Slattery wrote:
>
>> I'm writing a Java object that runs a Perl script. I use the Process 
>> object to do this. I set everything up, then call the waitFor() method - 
>> and the Java program hangs. I've put debug logging into both the Perl 
>> script and the java program, so I see that the Perl script runs all the 
>> way through, but the last thing the Java program does is execute 
>> waitFor().
>
>The most common bug around this sort of thing is that the parent process 
>doesn't read all the child's output from its standard output stream. The 
>buffer for the pipe between the two fills up, and the child then gets 
>blocked waiting for it to empty so that it can finish writing, which of 
>course never happens because the parent is waiting for the child to 
>terminate. Deadlock ensues.
>
>However, from what you say, it sounds like the Perl script is terminating. 
>Is that definitely the case? Could it be that the script finishes running, 
>but the buffer is never drained, so the Perl interpreter doesn't exit?

I guess it was something like that. Putting the processes to read
STDOUT and STDERR in separate threads did the trick. But the Perl
script definitely finished, so ????? 

-- 
Tim Slattery
Slattery_T@bls.gov
http://members.cox.net/slatteryt

On 12/20/2010 1:10 PM, Tim Slattery wrote:

> I guess it was something like that. Putting the processes to read
> STDOUT and STDERR in separate threads did the trick. But the Perl
> script definitely finished, so ?????


I don't know if this is documented somewhere but it's well known.  For 
whatever reason, Process doesn't consider the process to be "done" until 
all of it's output is read.  Possibly to avoid issues where one thread 
is still reading/processing output and another thread thinks otherwise.

Tim Slattery <Slattery_T@bls.gov> writes:

> Tom Anderson <twic@urchin.earth.li> wrote:
>
>>On Mon, 20 Dec 2010, Tim Slattery wrote:
>>
>>> I'm writing a Java object that runs a Perl script. I use the Process 
>>> object to do this. I set everything up, then call the waitFor() method - 
>>> and the Java program hangs. I've put debug logging into both the Perl 
>>> script and the java program, so I see that the Perl script runs all the 
>>> way through, but the last thing the Java program does is execute 
>>> waitFor().
>>
>>The most common bug around this sort of thing is that the parent process 
>>doesn't read all the child's output from its standard output stream. The 
>>buffer for the pipe between the two fills up, and the child then gets 
>>blocked waiting for it to empty so that it can finish writing, which of 
>>course never happens because the parent is waiting for the child to 
>>terminate. Deadlock ensues.
>>
>>However, from what you say, it sounds like the Perl script is terminating. 
>>Is that definitely the case? Could it be that the script finishes running, 
>>but the buffer is never drained, so the Perl interpreter doesn't exit?
>
> I guess it was something like that. Putting the processes to read
> STDOUT and STDERR in separate threads did the trick. But the Perl
> script definitely finished, so ????? 

The Perl interpreter is written in C, so it probably ends by calling
exit().  One of the things exit() does is to flush all open buffered
output streams.  If any of those is a pipe, it could block at that
point.

-- 
Jim Janney

On 21/12/2010 9:16 AM, markspace wrote:
> For whatever reason, Process doesn't consider the process to be "done" until
> all of it's output is read.

This is not so. The issue is that the child process can't exit if it is 
blocked doing output because the reading end hasn't read it. Process 
itself couldn't care less.