From user42@zip.com.au

The program below prints

  WRITE 4096 bytes
  FLUSH
  WRITE 4096 bytes
  FLUSH
  WRITE 4096 bytes
  FLUSH
  WRITE 4096 bytes
  FLUSH

where I hoped the :perlio layer wouldn't call Flush on the sub-layer
unless/until a flush from the toplevel.

Nosing around it looks like the :perlio code for "my buffer is full, I
have to write it to the sublayer" calls its own flush func to do that
job, resulting in what I think are unnecessary Flushes on the sublayer.

The commented-out "​:encoding(ascii)" line in the program does the same
thing, but in 1024 byte blocks. Nosing around I guess :encoding shares
some of the buffering layer code.

(This is assuming I understand the flush func correctly as meaning
"force output sofar to go on the wire, if it hasn't already". The
perliol pod isn't quite as clear as it might be.)

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'

From user42@zip.com.au

multiflush.pl

From @jkeenan

On Thu Jul 24 18​:21​:26 2008, kryde wrote​:

The program below prints

WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH

where I hoped the :perlio layer wouldn't call Flush on the sub-layer
unless/until a flush from the toplevel.

Nosing around it looks like the :perlio code for "my buffer is full, I
have to write it to the sublayer" calls its own flush func to do that
job, resulting in what I think are unnecessary Flushes on the
sublayer.

The commented-out "​:encoding(ascii)" line in the program does the same
thing, but in 1024 byte blocks. Nosing around I guess :encoding
shares
some of the buffering layer code.

(This is assuming I understand the flush func correctly as meaning
"force output sofar to go on the wire, if it hasn't already". The
perliol pod isn't quite as clear as it might be.)

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

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

From @Leont

On Thu Jul 24 18​:21​:26 2008, kryde wrote​:

The program below prints

WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH

where I hoped the :perlio layer wouldn't call Flush on the sub-layer
unless/until a flush from the toplevel.

Nosing around it looks like the :perlio code for "my buffer is full, I
have to write it to the sublayer" calls its own flush func to do that
job, resulting in what I think are unnecessary Flushes on the
sublayer.

The commented-out "​:encoding(ascii)" line in the program does the same
thing, but in 1024 byte blocks. Nosing around I guess :encoding
shares
some of the buffering layer code.

(This is assuming I understand the flush func correctly as meaning
"force output sofar to go on the wire, if it hasn't already". The
perliol pod isn't quite as clear as it might be.)

Yeah, this is because flush is a little too overloaded. It's suboptimal
but not really wrong (as is much in PerlIO).

Leon

From @nwc10

On Mon, May 27, 2013 at 05​:17​:34AM -0700, Leon Timmermans via RT wrote​:

On Thu Jul 24 18​:21​:26 2008, kryde wrote​:

The program below prints

WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH
WRITE 4096 bytes
FLUSH

where I hoped the :perlio layer wouldn't call Flush on the sub-layer
unless/until a flush from the toplevel.

Nosing around it looks like the :perlio code for "my buffer is full, I
have to write it to the sublayer" calls its own flush func to do that
job, resulting in what I think are unnecessary Flushes on the
sublayer.

The commented-out "​:encoding(ascii)" line in the program does the same
thing, but in 1024 byte blocks. Nosing around I guess :encoding
shares
some of the buffering layer code.

(This is assuming I understand the flush func correctly as meaning
"force output sofar to go on the wire, if it hasn't already". The
perliol pod isn't quite as clear as it might be.)

Yeah, this is because flush is a little too overloaded. It's suboptimal
but not really wrong (as is much in PerlIO).

Gosh yes, sorry I missed this at the time.
(I'd just moved job and was moving house)

I remember commenting this to Nick Ing-Simmons - that flush is used to mean
both "regular empty the buffer" and "urgent, to the disk, now!", and IIRC he
agreed that it was a design mistake.

I don't think that we can fix this without a major rewrite of PerlIO.

Nicholas Clark