perl Write filehandle blocks.

[kiranmn]

hi,

First parent do a fork, parent waits for child to finish , child
runs a command "head" and exits. After waiting parent sleep fror 1
hours and continue doing same thing. when i write a file to t "open2",
write filehandle, it just hangs there, what is the reason.

Following is my code. It stops at " now writing to write fd
". Please help me.

Thanking you,
regards,
kiran
========================================
#!/usr/bin/perl -I../lib


#use strict;
use Carp qw(verbose);
use IPC::Open2;
use Symbol;
my $WTR;
my $RDR;
while(1)
{
if($kid=fork)
{
waitpid($kid,0);
}
else
{
while(<STDIN>)
{
$ref->{"mail"}.=$_;
}
$WTR = gensym(); # get a reference to a typeglob
$RDR = gensym(); # and another one
$pid=open2($RDR, $WTR, "/usr/bin/head ");
print "now writing to write fd\n";
$oo=select $WTR;
$|=1;
select $oo;
print $WTR "$ref->{\"mail\"}";
print "closing writing fd\n";
close($WTR);
print "going to reader\n";
while(<$RDR>)
{
print "$_";
}
print "comming out of while reader\n";
close($RDR);
exit;
}
sleep (3600);
}

 

[Tad McClellan]

#!/usr/bin/perl -I../lib


#use strict;

You lose all of the benefits of strict when you comment it out like that.

print "$_";

perldoc -q vars

What’s wrong with always quoting "$vars"?

 

[kiranmn]

if i run the code like "cat passwd|perl head.pl", if size of passwd
file is less it works fine, if it is more than 4k it hangs.

 

[Joe Smith]

First parent do a fork, parent waits for child to finish , child
runs a command "head" and exits. After waiting parent sleep fror 1
hours and continue doing same thing. when i write a file to t "open2",
write filehandle, it just hangs there...

use IPC::Open2;
$pid=open2($RDR, $WTR, "/usr/bin/head ");

perldoc IPC::Open2

This whole affair is quite dangerous, as you may block forever. It
assumes it's going to talk to something like bc, both writing to it and
reading from it. This is presumably safe because you "know" that com-
mands like bc will read a line at a time and output a line at a time.
Programs like sort that read their entire input stream first, however,
are quite apt to cause deadlock.

It's cases like this where the parent should fork two children:
one that can block while writing to $WTR yet not preventing the other
fork from reading from $RDR at the same time.

-Joe

 

[Uri Guttman]

JS> perldoc IPC::Open2


JS> It's cases like this where the parent should fork two children:
JS> one that can block while writing to $WTR yet not preventing the other
JS> fork from reading from $RDR at the same time.

way too much work when an event loop in the parent can handle the open2
and more all by itself. your idea can still deadlock if the parent
doesn't manage correctly the i/o of the pair of children.

uri

 

[xhoster]

JS> perldoc IPC::Open2

JS> It's cases like this where the parent should fork two children:
JS> one that can block while writing to $WTR yet not preventing the
other JS> fork from reading from $RDR at the same time.

way too much work when an event loop in the parent can handle the open2
and more all by itself.

I have a hard time seeing how coding a simple fork is more work than
writing an event loop.

your idea can still deadlock if the parent
doesn't manage correctly the i/o of the pair of children.

Sure, and it is possible to code an event loop incorrectly.

Xho

 

[Uri Guttman]

JS> It's cases like this where the parent should fork two children:
JS> one that can block while writing to $WTR yet not preventing the
x> I have a hard time seeing how coding a simple fork is more work than
x> writing an event loop.

the previous post mentioned TWO forks and managing that is much more
difficult than one fork with only input or output (or even open2 if
blocking can't happen). using an event loop eliminated the deadlock
issue and allows for scaling to more things such as sockets, guis, etc.

x> Sure, and it is possible to code an event loop incorrectly.

who write event loops anymore? there are several modules that do all the
work and in general they are fairly easy to use. the biggest issue is
altering your mindset to a callback style of coding.

uri