Implementation of file input operator <>

[himanshu.garg]

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

 

[Uri Guttman]

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

 

[Ben Morrow]

Quoth (e-mail address removed):

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.cerl_do_readline, which calls sv.cerl_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

 

[himanshu.garg]

Quoth (e-mail address removed):




<> is implemented as pp_readline in pp_hot.c, which calls
pp_hot.cerl_do_readline, which calls sv.cerl_sv_gets, which calls
PerlIO_read to perform the actual read. Note that understanding the Perl
IO system is not easy.


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

 

[Uri Guttman]

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

 

[xhoster]

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.