Excessive wait time after fork

Hi,

I noticed that after fork, the wait time is excessive (my other
test waited for hours). Is this a known problem, how to get around it?

This happens with ForkManager module also.

=09
Any pointers on what's going on is appreciated!

Bob


########code########
#!/usr/bin/env perl

my [at] in =3D [at] ARGV;
my $num =3D scalar [at] in;

my [at] children;

for (my $i =3D 0; $i < $num; $i++) {
my $pid =3D fork();
if ($pid) { # parent
push [at] children, $pid;
print "parent $pid ", scalar localtime(),"\n";
} elsif ($pid =3D=3D 0) { # child
print "child $i BEFORE sub call : ", scalar localtime(),"\n";
#sub
my $ref=3DlongP($in[$i]);
print "child $i AFTER sub call :", scalar localtime()," numKeys:",
scalar keys %{$ref},"\n";
#sleep $in[$i];
exit;
} else {
print STDERR "couldn't fork\n";
}
}

print "before WAIT : ", scalar localtime(),"\n";
foreach my $child ( [at] children) {
waitpid($child, 0);
print "Child $child done at ", scalar localtime(),"\n";
}
print "after WAIT : ", scalar localtime(),"\n";

print "Finished at ", scalar localtime(),"\n";

sub longP {
my ($i)=3D [at] _;
my %h=3D();
for my $j (0 .. $i * 1000000) {
$h{$j}=3D$j*100;
}
return \%h;
}


########command########
myTestOfFork 100 20 30 4 5 6 > O_myTestOfFork

########output########
parent 3052 Sat Apr 2 10:44:54 2011
parent 3053 Sat Apr 2 10:44:54 2011
parent 3054 Sat Apr 2 10:44:54 2011
parent 3055 Sat Apr 2 10:44:54 2011
parent 3056 Sat Apr 2 10:44:54 2011
child 3 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 3 AFTER sub call :Sat Apr 2 10:45:01 2011 numKeys:4000001
child 4 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 4 AFTER sub call :Sat Apr 2 10:45:04 2011 numKeys:5000001
child 5 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 5 AFTER sub call :Sat Apr 2 10:45:06 2011 numKeys:6000001
child 1 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 1 AFTER sub call :Sat Apr 2 10:45:41 2011 numKeys:20000001
child 2 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 2 AFTER sub call :Sat Apr 2 10:45:56 2011 numKeys:30000001
child 0 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 0 AFTER sub call :Sat Apr 2 10:48:45 2011 numKeys:100000001 #
all sub calls are finished at this time
parent 3057 Sat Apr 2 10:44:54 2011
before WAIT : Sat Apr 2 10:44:54 2011
Child 3052 done at Sat Apr 2 10:50:21 2011
Child 3053 done at Sat Apr 2 10:50:21 2011
Child 3054 done at Sat Apr 2 10:50:21 2011
Child 3055 done at Sat Apr 2 10:50:21 2011
Child 3056 done at Sat Apr 2 10:50:21 2011
Child 3057 done at Sat Apr 2 10:50:21 2011
after WAIT : Sat Apr 2 10:50:21 2011 #
why wait for additional 1:36 ?
Finished at Sat Apr 2 10:50:21 2011


This e-mail message may contain privileged and/or confidential information,=
and is intended to be received only by persons entitled
to receive such information. If you have received this e-mail in error, ple=
ase notify the sender immediately. Please delete it and
all attachments from any servers, hard drives or any other media. Other use=
of this e-mail by you is strictly prohibited.

All e-mails and attachments sent and received are subject to monitoring, re=
ading and archival by Monsanto, including its
subsidiaries. The recipient of this e-mail is solely responsible for checki=
ng for the presence of "Viruses" or other "Malware".
Monsanto, along with its subsidiaries, accepts no liability for any damage =
caused by any such code transmitted by or accompanying
this e-mail or any attachment.


The information contained in this email may be subject to the export contro=
l laws and regulations of the United States, potentially
including but not limited to the Export Administration Regulations (EAR) an=
d sanctions regulations issued by the U.S. Department of
Treasury, Office of Foreign Asset Controls (OFAC). As a recipient of this =
information you are obligated to comply with all
applicable U.S. export laws and regulations.


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/
nengbing.tao [ Sa, 02 April 2011 18:06 ] [ ID #2057590 ]

Re: Excessive wait time after fork

On Sat, Apr 2, 2011 at 12:06, TAO, NENGBING [AG/1005]
<nengbing.tao [at] monsanto.com> wrote:
> Hi,
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0I noticed that after fork, the wait time is ex=
cessive (my other
> test waited for hours). Is this a known problem, how to get around it?
snip
> child 3 AFTER =C2=A0sub call :Sat Apr =C2=A02 10:45:01 2011 numKeys:40000=
01
> child 4 BEFORE sub call : Sat Apr =C2=A02 10:44:54 2011
> child 4 AFTER =C2=A0sub call :Sat Apr =C2=A02 10:45:04 2011 numKeys:50000=
01
> child 5 BEFORE sub call : Sat Apr =C2=A02 10:44:54 2011
> child 5 AFTER =C2=A0sub call :Sat Apr =C2=A02 10:45:06 2011 numKeys:60000=
01
> child 1 BEFORE sub call : Sat Apr =C2=A02 10:44:54 2011
> child 1 AFTER =C2=A0sub call :Sat Apr =C2=A02 10:45:41 2011 numKeys:20000=
001
> child 2 BEFORE sub call : Sat Apr =C2=A02 10:44:54 2011
> child 2 AFTER =C2=A0sub call :Sat Apr =C2=A02 10:45:56 2011 numKeys:30000=
001
> child 0 BEFORE sub call : Sat Apr =C2=A02 10:44:54 2011
> child 0 AFTER =C2=A0sub call :Sat Apr =C2=A02 10:48:45 2011 numKeys:10000=
0001 =C2=A0 #
snip

My bet is you don't have enough RAM to hold all of that data; your OS
is being forced to use swap. Your poor machine is so swamped it is
taking that long to get back to normal.

Each key in your hash is probably taking up around fifteen bytes and
each value is probably around four bytes (if not eight). You have
165,000,006 entries. That means you need around 3 gigabytes of RAM
for the data alone. That doesn't count the hash that holds the data,
perl itself, or any other programs you may be running.


--
Chas. Owens
wonkden.net
The most important skill a programmer can have is the ability to read.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/
chas.owens [ Mo, 04 April 2011 13:40 ] [ ID #2057591 ]

RE: Excessive wait time after fork

SGksDQoNCj5Gcm9tOiBDaGFzLiBPd2VucyBbbWFpbHRvOmNoYXMub3dlbnNA Z21haWwuY29tXSAN
Cj5TZW50OiBNb25kYXksIEFwcmlsIDA0LCAyMDExIDY6NDAgQU0NCg0KPk15 IGJldCBpcyB5b3Ug
ZG9uJ3QgaGF2ZSBlbm91Z2ggUkFNIHRvIGhvbGQgYWxsIG9mIHRoYXQgZGF0 YTsgeW91ciBPUw0K
PmlzIGJlaW5nIGZvcmNlZCB0byB1c2Ugc3dhcC4gIFlvdXIgcG9vciBtYWNo aW5lIGlzIHNvIHN3
YW1wZWQgaXQgaXMNCj50YWtpbmcgdGhhdCBsb25nIHRvIGdldCBiYWNrIHRv IG5vcm1hbC4NCg0K
PkVhY2gga2V5IGluIHlvdXIgaGFzaCBpcyBwcm9iYWJseSB0YWtpbmcgdXAg YXJvdW5kIGZpZnRl
ZW4gYnl0ZXMgYW5kDQo+ZWFjaCB2YWx1ZSBpcyBwcm9iYWJseSBhcm91bmQg Zm91ciBieXRlcyAo
aWYgbm90IGVpZ2h0KS4gIFlvdSBoYXZlDQo+MTY1LDAwMCwwMDYgZW50cmll cy4gIFRoYXQgbWVh
bnMgeW91IG5lZWQgYXJvdW5kIDMgZ2lnYWJ5dGVzIG9mIFJBTQ0KPmZvciB0 aGUgZGF0YSBhbG9u
ZS4gIFRoYXQgZG9lc24ndCBjb3VudCB0aGUgaGFzaCB0aGF0IGhvbGRzIHRo ZSBkYXRhLA0KPnBl
cmwgaXRzZWxmLCBvciBhbnkgb3RoZXIgcHJvZ3JhbXMgeW91IG1heSBiZSBy dW5uaW5nLg0KDQoN
CllvdSBoYXZlIGEgZ29vZCBwb2ludC4gSSBjb3VsZCBub3QgdGhpbmsgb2Yg YW55dGhpbmcgZWxz
ZSwgYW5kIHN1c3BlY3RlZCBpdCBtaWdodCBiZSB0aGUgY2F1c2UuDQoNCkJ1 dDogVGhlIHNlcnZl
cnMgdGhhdCBJIGhhdmUgdGVzdGVkIGhhdmUgbGlnaHQgbG9hZCBhbmQgaGF2 ZSBsYXJnZSBtZW1v
cnkgKGF0IGxlYXN0IDEwIHRpbWVzIG1vcmUgdGhhbiB0aGUgcHJvY2VzcyB0 aGF0IEkgcmFuIHdv
dWxkIG5lZWQpLiBJIGNob29zZSB0aG9zZSBudW1iZXJzIHRvIHNpbXVsYXRl IG1lbW9yeSB1c2Ug
c2ltaWxhciB0byBteSByZWFsIHByb2Nlc3MuIFNpbmNlICJ0b3AiIGNvbW1h bmQgb24gTGludXgg
YWxtb3N0IGFsd2F5cyBzaG93cyAidXNlZCIgdmFsdWUgdGhhdCBuZWFybHkg bWF0Y2ggdGhlICJ0
b3RhbCIgYW5kIExpbnV4IGxpa2UgdG8gdXNlIGFueSBzcGFyZSBtZW1vcnkg dG8gY2FjaGUgZGlz
ayBibG9ja3MsIEkgY2FuIGhhcmRseSB0ZWxsLiAiZnJlZSAtbSAiIGRpZCBz aG93IHRoYXQgbGVz
cyB0aGFuIGhhbGYgb2YgdGhlIHRvdGFsIG1lbW9yeSBpcyB1c2VkLiBTbyBJ IGRvbid0IGJlbGll
dmUgdGhlIHNlcnZlciBpcyBzd2FtcGVkLiANCg0KDQoNCg0KVGhhbmtzDQoN Cg0KDQoNCg0KDQoN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENoYXMuIE93 ZW5zIFttYWlsdG86
Y2hhcy5vd2Vuc0BnbWFpbC5jb21dIA0KU2VudDogTW9uZGF5LCBBcHJpbCAw NCwgMjAxMSA2OjQw
IEFNDQpUbzogVEFPLCBORU5HQklORyBbQUcvMTAwNV0NCkNjOiBiZWdpbm5l cnMtZGlnZXN0LWhl
bHBAcGVybC5vcmc7IGJlZ2lubmVyc0BwZXJsLm9yZw0KU3ViamVjdDogUmU6 IEV4Y2Vzc2l2ZSB3
YWl0IHRpbWUgYWZ0ZXIgZm9yaw0KDQpPbiBTYXQsIEFwciAyLCAyMDExIGF0 IDEyOjA2LCBUQU8s
IE5FTkdCSU5HIFtBRy8xMDA1XQ0KPG5lbmdiaW5nLnRhb0Btb25zYW50by5j b20+IHdyb3RlOg0K
PiBIaSwNCj4NCj4gwqAgwqAgwqAgwqBJIG5vdGljZWQgdGhhdCBhZnRlciBm b3JrLCB0aGUgd2Fp
dCB0aW1lIGlzIGV4Y2Vzc2l2ZSAobXkgb3RoZXINCj4gdGVzdCB3YWl0ZWQg Zm9yIGhvdXJzKS4g
SXMgdGhpcyBhIGtub3duIHByb2JsZW0sIGhvdyB0byBnZXQgYXJvdW5kIGl0 Pw0Kc25pcA0KPiBj
aGlsZCAzIEFGVEVSIMKgc3ViIGNhbGwgOlNhdCBBcHIgwqAyIDEwOjQ1OjAx IDIwMTEgbnVtS2V5
czo0MDAwMDAxDQo+IGNoaWxkIDQgQkVGT1JFIHN1YiBjYWxsIDogU2F0IEFw ciDCoDIgMTA6NDQ6
NTQgMjAxMQ0KPiBjaGlsZCA0IEFGVEVSIMKgc3ViIGNhbGwgOlNhdCBBcHIg wqAyIDEwOjQ1OjA0
IDIwMTEgbnVtS2V5czo1MDAwMDAxDQo+IGNoaWxkIDUgQkVGT1JFIHN1YiBj YWxsIDogU2F0IEFw
ciDCoDIgMTA6NDQ6NTQgMjAxMQ0KPiBjaGlsZCA1IEFGVEVSIMKgc3ViIGNh bGwgOlNhdCBBcHIg
wqAyIDEwOjQ1OjA2IDIwMTEgbnVtS2V5czo2MDAwMDAxDQo+IGNoaWxkIDEg QkVGT1JFIHN1YiBj
YWxsIDogU2F0IEFwciDCoDIgMTA6NDQ6NTQgMjAxMQ0KPiBjaGlsZCAxIEFG VEVSIMKgc3ViIGNh
bGwgOlNhdCBBcHIgwqAyIDEwOjQ1OjQxIDIwMTEgbnVtS2V5czoyMDAwMDAw MQ0KPiBjaGlsZCAy
IEJFRk9SRSBzdWIgY2FsbCA6IFNhdCBBcHIgwqAyIDEwOjQ0OjU0IDIwMTEN Cj4gY2hpbGQgMiBB
RlRFUiDCoHN1YiBjYWxsIDpTYXQgQXByIMKgMiAxMDo0NTo1NiAyMDExIG51 bUtleXM6MzAwMDAw
MDENCj4gY2hpbGQgMCBCRUZPUkUgc3ViIGNhbGwgOiBTYXQgQXByIMKgMiAx MDo0NDo1NCAyMDEx
DQo+IGNoaWxkIDAgQUZURVIgwqBzdWIgY2FsbCA6U2F0IEFwciDCoDIgMTA6 NDg6NDUgMjAxMSBu
dW1LZXlzOjEwMDAwMDAwMSDCoCAjDQpzbmlwDQoNCk15IGJldCBpcyB5b3Ug ZG9uJ3QgaGF2ZSBl
bm91Z2ggUkFNIHRvIGhvbGQgYWxsIG9mIHRoYXQgZGF0YTsgeW91ciBPUw0K aXMgYmVpbmcgZm9y
Y2VkIHRvIHVzZSBzd2FwLiAgWW91ciBwb29yIG1hY2hpbmUgaXMgc28gc3dh bXBlZCBpdCBpcw0K
dGFraW5nIHRoYXQgbG9uZyB0byBnZXQgYmFjayB0byBub3JtYWwuDQoNCkVh Y2gga2V5IGluIHlv
dXIgaGFzaCBpcyBwcm9iYWJseSB0YWtpbmcgdXAgYXJvdW5kIGZpZnRlZW4g Ynl0ZXMgYW5kDQpl
YWNoIHZhbHVlIGlzIHByb2JhYmx5IGFyb3VuZCBmb3VyIGJ5dGVzIChpZiBu b3QgZWlnaHQpLiAg
WW91IGhhdmUNCjE2NSwwMDAsMDA2IGVudHJpZXMuICBUaGF0IG1lYW5zIHlv dSBuZWVkIGFyb3Vu
ZCAzIGdpZ2FieXRlcyBvZiBSQU0NCmZvciB0aGUgZGF0YSBhbG9uZS4gIFRo YXQgZG9lc24ndCBj
b3VudCB0aGUgaGFzaCB0aGF0IGhvbGRzIHRoZSBkYXRhLA0KcGVybCBpdHNl bGYsIG9yIGFueSBv
dGhlciBwcm9ncmFtcyB5b3UgbWF5IGJlIHJ1bm5pbmcuDQoNCg0KLS0gDQpD aGFzLiBPd2Vucw0K
d29ua2Rlbi5uZXQNClRoZSBtb3N0IGltcG9ydGFudCBza2lsbCBhIHByb2dy YW1tZXIgY2FuIGhh
dmUgaXMgdGhlIGFiaWxpdHkgdG8gcmVhZC4NClRoaXMgZS1tYWlsIG1lc3Nh Z2UgbWF5IGNvbnRh
aW4gcHJpdmlsZWdlZCBhbmQvb3IgY29uZmlkZW50aWFsIGluZm9ybWF0aW9u LCBhbmQgaXMgaW50
ZW5kZWQgdG8gYmUgcmVjZWl2ZWQgb25seSBieSBwZXJzb25zIGVudGl0bGVk CnRvIHJlY2VpdmUg
c3VjaCBpbmZvcm1hdGlvbi4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl LW1haWwgaW4gZXJy
b3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseS4gUGxl YXNlIGRlbGV0ZSBp
dCBhbmQKYWxsIGF0dGFjaG1lbnRzIGZyb20gYW55IHNlcnZlcnMsIGhhcmQg ZHJpdmVzIG9yIGFu
eSBvdGhlciBtZWRpYS4gT3RoZXIgdXNlIG9mIHRoaXMgZS1tYWlsIGJ5IHlv dSBpcyBzdHJpY3Rs
eSBwcm9oaWJpdGVkLgoKQWxsIGUtbWFpbHMgYW5kIGF0dGFjaG1lbnRzIHNl bnQgYW5kIHJlY2Vp
dmVkIGFyZSBzdWJqZWN0IHRvIG1vbml0b3JpbmcsIHJlYWRpbmcgYW5kIGFy Y2hpdmFsIGJ5IE1v
bnNhbnRvLCBpbmNsdWRpbmcgaXRzCnN1YnNpZGlhcmllcy4gVGhlIHJlY2lw aWVudCBvZiB0aGlz
IGUtbWFpbCBpcyBzb2xlbHkgcmVzcG9uc2libGUgZm9yIGNoZWNraW5nIGZv ciB0aGUgcHJlc2Vu
Y2Ugb2YgIlZpcnVzZXMiIG9yIG90aGVyICJNYWx3YXJlIi4KTW9uc2FudG8s IGFsb25nIHdpdGgg
aXRzIHN1YnNpZGlhcmllcywgYWNjZXB0cyBubyBsaWFiaWxpdHkgZm9yIGFu eSBkYW1hZ2UgY2F1
c2VkIGJ5IGFueSBzdWNoIGNvZGUgdHJhbnNtaXR0ZWQgYnkgb3IgYWNjb21w YW55aW5nCnRoaXMg
ZS1tYWlsIG9yIGFueSBhdHRhY2htZW50LgoKClRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4g
dGhpcyBlbWFpbCBtYXkgYmUgc3ViamVjdCB0byB0aGUgZXhwb3J0IGNvbnRy b2wgbGF3cyBhbmQg
cmVndWxhdGlvbnMgb2YgdGhlIFVuaXRlZCBTdGF0ZXMsIHBvdGVudGlhbGx5 CmluY2x1ZGluZyBi
dXQgbm90IGxpbWl0ZWQgdG8gdGhlIEV4cG9ydCBBZG1pbmlzdHJhdGlvbiBS ZWd1bGF0aW9ucyAo
RUFSKSBhbmQgc2FuY3Rpb25zIHJlZ3VsYXRpb25zIGlzc3VlZCBieSB0aGUg VS5TLiBEZXBhcnRt
ZW50IG9mClRyZWFzdXJ5LCBPZmZpY2Ugb2YgRm9yZWlnbiBBc3NldCBDb250 cm9scyAoT0ZBQyku
ICBBcyBhIHJlY2lwaWVudCBvZiB0aGlzIGluZm9ybWF0aW9uIHlvdSBhcmUg b2JsaWdhdGVkIHRv
IGNvbXBseSB3aXRoIGFsbAphcHBsaWNhYmxlIFUuUy4gZXhwb3J0IGxhd3Mg YW5kIHJlZ3VsYXRp
b25zLgo=
nengbing.tao [ Mo, 04 April 2011 17:55 ] [ ID #2057651 ]

RE: Excessive wait time after fork

It seems the problem can be solved by using POSIX exit.
(http://perldoc.perl.org/functions/exit.html )
Thanks to Chris who is in our IT department for pointing me to this. I
should have read it more carefully!

" The exit() function does not always exit immediately. It calls any
defined END routines first, but these END routines may not themselves
abort the exit. Likewise any object destructors that need to be called
are called before the real exit. If this is a problem, you can call
POSIX:_exit($status) to avoid END and destructor processing."

Thanks all!

-----Original Message-----
From: TAO, NENGBING [AG/1005]
Sent: Saturday, April 02, 2011 11:07 AM
To: 'beginners-digest-help [at] perl.org'; beginners [at] perl.org
Subject: Excessive wait time after fork

Hi,

I noticed that after fork, the wait time is excessive (my other
test waited for hours). Is this a known problem, how to get around it?

This happens with ForkManager module also.

=09
Any pointers on what's going on is appreciated!

Bob


########code########
#!/usr/bin/env perl

my [at] in =3D [at] ARGV;
my $num =3D scalar [at] in;

my [at] children;

for (my $i =3D 0; $i < $num; $i++) {
my $pid =3D fork();
if ($pid) { # parent
push [at] children, $pid;
print "parent $pid ", scalar localtime(),"\n";
} elsif ($pid =3D=3D 0) { # child
print "child $i BEFORE sub call : ", scalar localtime(),"\n";
#sub
my $ref=3DlongP($in[$i]);
print "child $i AFTER sub call :", scalar localtime()," numKeys:",
scalar keys %{$ref},"\n";
#sleep $in[$i];
exit;
} else {
print STDERR "couldn't fork\n";
}
}

print "before WAIT : ", scalar localtime(),"\n";
foreach my $child ( [at] children) {
waitpid($child, 0);
print "Child $child done at ", scalar localtime(),"\n";
}
print "after WAIT : ", scalar localtime(),"\n";

print "Finished at ", scalar localtime(),"\n";

sub longP {
my ($i)=3D [at] _;
my %h=3D();
for my $j (0 .. $i * 1000000) {
$h{$j}=3D$j*100;
}
return \%h;
}


########command########
myTestOfFork 100 20 30 4 5 6 > O_myTestOfFork

########output########
parent 3052 Sat Apr 2 10:44:54 2011
parent 3053 Sat Apr 2 10:44:54 2011
parent 3054 Sat Apr 2 10:44:54 2011
parent 3055 Sat Apr 2 10:44:54 2011
parent 3056 Sat Apr 2 10:44:54 2011
child 3 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 3 AFTER sub call :Sat Apr 2 10:45:01 2011 numKeys:4000001
child 4 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 4 AFTER sub call :Sat Apr 2 10:45:04 2011 numKeys:5000001
child 5 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 5 AFTER sub call :Sat Apr 2 10:45:06 2011 numKeys:6000001
child 1 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 1 AFTER sub call :Sat Apr 2 10:45:41 2011 numKeys:20000001
child 2 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 2 AFTER sub call :Sat Apr 2 10:45:56 2011 numKeys:30000001
child 0 BEFORE sub call : Sat Apr 2 10:44:54 2011
child 0 AFTER sub call :Sat Apr 2 10:48:45 2011 numKeys:100000001 #
all sub calls are finished at this time
parent 3057 Sat Apr 2 10:44:54 2011
before WAIT : Sat Apr 2 10:44:54 2011
Child 3052 done at Sat Apr 2 10:50:21 2011
Child 3053 done at Sat Apr 2 10:50:21 2011
Child 3054 done at Sat Apr 2 10:50:21 2011
Child 3055 done at Sat Apr 2 10:50:21 2011
Child 3056 done at Sat Apr 2 10:50:21 2011
Child 3057 done at Sat Apr 2 10:50:21 2011
after WAIT : Sat Apr 2 10:50:21 2011 #
why wait for additional 1:36 ?
Finished at Sat Apr 2 10:50:21 2011


This e-mail message may contain privileged and/or confidential information,=
and is intended to be received only by persons entitled
to receive such information. If you have received this e-mail in error, ple=
ase notify the sender immediately. Please delete it and
all attachments from any servers, hard drives or any other media. Other use=
of this e-mail by you is strictly prohibited.

All e-mails and attachments sent and received are subject to monitoring, re=
ading and archival by Monsanto, including its
subsidiaries. The recipient of this e-mail is solely responsible for checki=
ng for the presence of "Viruses" or other "Malware".
Monsanto, along with its subsidiaries, accepts no liability for any damage =
caused by any such code transmitted by or accompanying
this e-mail or any attachment.


The information contained in this email may be subject to the export contro=
l laws and regulations of the United States, potentially
including but not limited to the Export Administration Regulations (EAR) an=
d sanctions regulations issued by the U.S. Department of
Treasury, Office of Foreign Asset Controls (OFAC). As a recipient of this =
information you are obligated to comply with all
applicable U.S. export laws and regulations.


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/
nengbing.tao [ Di, 05 April 2011 18:56 ] [ ID #2057652 ]
Perl » gmane.comp.lang.perl.beginners » Excessive wait time after fork

Vorheriges Thema: Capturing the output of a shell command
Nächstes Thema: Re: Perl Hash Comparison and concatenate result from %hash2 comparedto %hash1 into %hash3