Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PerlIO::via::QuotedPrint not flushing #9431

Open
p5pRT opened this issue Jul 26, 2008 · 4 comments
Open

PerlIO::via::QuotedPrint not flushing #9431

p5pRT opened this issue Jul 26, 2008 · 4 comments

Comments

@p5pRT
Copy link

p5pRT commented Jul 26, 2008

Migrated from rt.perl.org#57288 (status was 'open')

Searchable as RT57288$

@p5pRT
Copy link
Author

p5pRT commented Jul 26, 2008

From user42@zip.com.au

When a PerlIO​::via​::QuotedPrint layer is pushed on an opened file,
autoflush or an explicit ->flush() doesn't send output to the file
immediately.

The program qp.pl below shows the problem. I hoped the OUT->flush would
make the "hello" appear in /tmp/foo immediately, but that doesn't
happen, not until after the program exits after the sleep.

I guess QuotedPrint doesn't supply a FLUSH routine, and the default for
PerlIO​::via in that case is to do nothing, so a top-level flush doesn't
reach the :perlio+​:unix full-buffered output layer below.

Several other PerlIO​::via output modules on cpan behave the same,
I guess having used QuotedPrint as a model. I wonder if either

- The PerlIO​::via docs could advise every output layer to supply a FLUSH
  function calling $fh->flush on the sublayer.

- PerlIO​::via could make such a "propagated" flush the default if you
  don't supply a FLUSH routine.

The latter could make life easier for straightforward non-buffering
transformer layers. The only question would be whether anyone has
omitted a FLUSH func deliberately wanting not to call flush on the
sublayer. That'd seem a bit unlikely to me, or only applicable to
something that was designed to be at the bottom of the stack anyway
(an output capture of some sort say) ...


Flags​:
  category=library
  severity=wishlist


Site configuration information for perl 5.10.0​:

Configured by Debian Project at Thu May 8 13​:32​:42 UTC 2008.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration​:
  Platform​:
  osname=linux, osvers=2.6.24.4, archname=i486-linux-gnu-thread-multi
  uname='linux ninsei 2.6.24.4 #1 smp preempt fri apr 18 15​:36​:09 pdt 2008 i686 gnulinux '
  config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=i486-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include'
  ccversion='', gccversion='4.2.3 (Debian 4.2.3-5)', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=4, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -L/usr/local/lib'
  libpth=/usr/local/lib /lib /usr/lib /usr/lib64
  libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
  perllibs=-ldl -lm -lpthread -lc -lcrypt
  libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so.5.10.0
  gnulibc_version='2.7'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib'

@p5pRT
Copy link
Author

p5pRT commented Jul 26, 2008

From user42@zip.com.au

qp.pl

@p5pRT
Copy link
Author

p5pRT commented May 26, 2013

From @jkeenan

On Fri Jul 25 17​:52​:12 2008, kryde wrote​:

When a PerlIO​::via​::QuotedPrint layer is pushed on an opened file,
autoflush or an explicit ->flush() doesn't send output to the file
immediately.

The program qp.pl below shows the problem. I hoped the OUT->flush
would
make the "hello" appear in /tmp/foo immediately, but that doesn't
happen, not until after the program exits after the sleep.

I guess QuotedPrint doesn't supply a FLUSH routine, and the default
for
PerlIO​::via in that case is to do nothing, so a top-level flush
doesn't
reach the :perlio+​:unix full-buffered output layer below.

Several other PerlIO​::via output modules on cpan behave the same,
I guess having used QuotedPrint as a model. I wonder if either

- The PerlIO​::via docs could advise every output layer to supply a
FLUSH
function calling $fh->flush on the sublayer.

- PerlIO​::via could make such a "propagated" flush the default if you
don't supply a FLUSH routine.

The latter could make life easier for straightforward non-buffering
transformer layers. The only question would be whether anyone has
omitted a FLUSH func deliberately wanting not to call flush on the
sublayer. That'd seem a bit unlikely to me, or only applicable to
something that was designed to be at the bottom of the stack anyway
(an output capture of some sort say) ...

This is one of three PerlIO-related tickets filed by the same user
several years ago. Is there anyone on list who could take a look at them?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented May 26, 2013

The RT System itself - Status changed from 'new' to 'open'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants