> Sebastian Bergmann wrote:
> > How about you read Zeev's excellent explanation of this issue in
> > Message-Id: <5.1.0.14.2.20021003111648.05550388@localhost>?
>
> Zeev may forgot some or misunderstood my patches.
> I have to take a look at SAPI code. IIRC it has been
> changed a little to work around broken flush.
> (I remember someone is tweaking output layer wrongly :)
>
> Without my patch, implicit flush is __USELESS__ that
> needs buffers.
>
> Okay, what you want to do with implicit_flush?
>
> I think it may be okay to enable implicit_flush for
> CLI? with buffering by default or not?
Yasuo,
Firstly output buffering != output layering. I don't not see fixing a
problem with the output layer (which implicit flush affects) in
output_buffering as the right thing to do. If there is a problem it
should be fixed in the output layer not output buffering otherwise
everytime output buffering is used we have to remember extra function
calls (IE centeralise and reduce).
Now as Zeev said the first bug seems to have been introduced by him
disabling output buffering in an implicit flush.
Lets have a look at the expected behaviour of implicit_flush (ignore
output buffering for now)
If implicit flush is OFF
And I call echo "blah", blah goes into a buffer and waits to be flushed
so that we cut down on I/O operations.
If Implicit flush is ON
And I call echo "Blah" blah goes into a buffer then flush() (what
actually happens is irrelevant this is the behaviour in general terms)
is called automatically so blah is sent to the client immeditaly.
This is useful if I am writing a command line app for example when I
don't want output to have to wait. Now I have not discussed why implicit
flush is always on in CLI as I would advocate defaulting this to on in
php-cli.ini but not statically code it, but that is irrelevant to this
issue at this second.
So lets look at what happens when output buffering is on. Lets say we
have multiple buffers:
+-----------------------+ -+
| TOP LEVEL BUFFER | |
+-----------------------+ | O
| | U
When this buffer is flushed | T // IF
ob_implicit_flush NOT implicit_flush
The output ends up in the | P // is use then
this affects
next layer | U // when this
buffer is changed
| | T
\|/ |
+-----------------------+ | B
| NEXT OUTPUT BUFFER | | U
+-----------------------+ | F
| | F
when this buffer is flushed | E
the data is passed to | R
the output layer | S
| |
\|/ --+
+-----------------------+
| OUTPUT LAYER | // It is in this
section where implicit flush has an affect
+-----------------------+ // which means
after every output operation from PHP then
// flush is called
making sure any remaining buffered (at server level)
// output is sent
to the client.
Now there is currently a bug in start_implicit_flush which turns output
buffering off for some reason (from what zeev said) so that is the place
to fix it NOT if the output_buffering layer.
If everyone agress this is the behaviour that we want lets work towards
this behaviour rather than adding hacks.
- James
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
