Hello,
Could you tell me which file in the perl source distro I should
look at for the implementation of the file input operators <>.
I suspect that one 'call' of <> is leading to two read system
calls.
Thank You,
HG
>>>>> "hg" == himanshu garg
hg> Could you tell me which file in the perl source distro I should
hg> look at for the implementation of the file input operators <>.
hg> I suspect that one 'call' of <> is leading to two read system
hg> calls.
do you think that is a bug? or why would 2 read calls bother you? it is
entirely possible for one readline call (what <> really is) could make
many read calls if the next input record (i didn't say line) overlaps
i/o buffer boundaries. perl's i/o subsystem (or stdio if you are using
that) manages read calls so it can satisfy your <> call. you want it to
make multiple read calls as needed.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Quoth himanshu.garg@gmail.com:
>
> Could you tell me which file in the perl source distro I should
> look at for the implementation of the file input operators <>.
<> is implemented as pp_readline in pp_hot.c, which calls
pp_hot.c:Perl_do_readline, which calls sv.c:Perl_sv_gets, which calls
PerlIO_read to perform the actual read. Note that understanding the Perl
IO system is not easy.
> I suspect that one 'call' of <> is leading to two read system
> calls.
As Uri pointed out, this is expected and desired. If you want to do your
own buffering, push a :unix layer or use sysread.
Ben
On Oct 25, 1:58 am, Ben Morrow
> Quoth himanshu.g...@gmail.com:
>
>
>
> > Could you tell me which file in the perl source distro I should
> > look at for the implementation of the file input operators <>.
>
> <> is implemented as pp_readline in pp_hot.c, which calls
> pp_hot.c:Perl_do_readline, which calls sv.c:Perl_sv_gets, which calls
> PerlIO_read to perform the actual read. Note that understanding the Perl
> IO system is not easy.
>
> > I suspect that one 'call' of <> is leading to two read system
> > calls.
>
> As Uri pointed out, this is expected and desired. If you want to do your
> own buffering, push a :unix layer or use sysread.
>
Thanks Uri and Ben,
There was a race condition in which the child process died during
the second read call and the parent kept waiting. Using a signal
handler for SIGCHLD required many code changes. Using sysread, I no
longer see the error.
Since multiple reads are entirely possible I will not go into the
source :)
Thank You,
HG
>>>>> "hg" == himanshu garg
hg> There was a race condition in which the child process died during
hg> the second read call and the parent kept waiting. Using a signal
hg> handler for SIGCHLD required many code changes. Using sysread, I no
hg> longer see the error.
this sounds like you are reading from a pipe connected to the child. in
general i always say use sysread on pipes and sockets and bypass perlIO
or stdio. managing buffering can be more work but you gain total control
over things which is more important. using an event loop also makes it
much easier to manage i/o on sockets and pipes.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Uri Guttman
> >>>>> "hg" == himanshu garg
>
> hg> There was a race condition in which the child process died
> during hg> the second read call and the parent kept waiting. Using a
> signal hg> handler for SIGCHLD required many code changes. Using sysread,
> I no hg> longer see the error.
>
> this sounds like you are reading from a pipe connected to the child.
But in that case the parent end of the pipe should be set eof when the
child dies, causing read to unblock. Or at least that is the why the pipes
I've used behaved. It sounds like something more weird than a simple pipe.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.