| To: | bug-IPC-Run [...] rt.cpan.org |
| From: | Richard Soderberg <rsod [...] cpan.org> |
| Subject: | [PATCH] problem with IPC-Run... |
| Date: | Wed, 2 Mar 2005 07:41:18 -0800 |
Begin forwarded message:
From: Toby Schaffer <jts@adc.idt.com>
Date: February 28, 2005 8:10:03 AM PST
To: rsod@cpan.org
Subject: Re: problem with IPC-Run...
hi richard,
below is a diff of Run.pm of a workaround for this problem for possible
inclusion into the next release of IPC-Run. i still don't know why
POSIX::read() is behaving the way it is, but the idea of looping until
all input is read seems better than an arbitrary 10k limit at any rate.
if you have time let me know what you think. thanks.
1345c1345,1353
< my $r = POSIX::read( $_[0], $s, 10_000 ) ;
---
Show quoted text
> my $r = POSIX::read( $_[0], $s, 4_096 ) ;
> my $r1 = $r ;
> while ( $r1 && $r1 == 4_096 ) {
> my $s1 = '' ;
> $r1 = POSIX::read( $_[0], $s1, 4_096 ) ;
> croak "$!: read( $_[0] )" if not($r1) and $! != POSIX::EINTR ;
> $s .= $s1 ;
> $r += ($r1 || 0) ;
> }
Toby Schaffer wrote:
Show quoted text> hi richard,
>
> my name is toby schaffer, and i work for a company called idt near
> atlanta, georgia. we use the ipc::run module quite a bit, so first
> thanks for taking up the maintainer mantle! i've recently run into a
> problem i was wondering if you could help with: the posix::read() call
> inside _read() behaves differently depending on IPCRUNDEBUG. when set
> to "data", the read returns 4096 out of 6206 characters from a child
> process and returns the remaining 2110 only when the child exits
> (finish() is called). when set to "details", read returns all 6206 at
> once. i've gone ahead and attached the output of both runs. the child
> process name is "dbAccess", i'm writing a command to it called
> "starrcgen" and then reading the result of that. in the "data" file,
> the reads occur at lines 1042 and 1051, in "details" at line 1326. the
> only difference between the runs is the IPCRUNDEBUG setting. this is
> with ipc-run 0.79, hosttype is an amd athlon 64 running fedora core 2.
> obviously some kind of buffering is involved, i'm just not familiar
> enough with low-level i/o to dig around...
>
> if you need any more info please don't hesitate to ask. any ideas or
> suggestions are greatly appreciated!
>
> thanks,
>
--
Toby Schaffer email: toby_schaffer@idt.com
CAD Engineer phone: 678-775-2969
Integrated Device Technology, Inc.
11555 Medlock Bridge Rd. Suite #200 Duluth, GA 30097