Thanks James, I thought PG(implict_flush) was deleting buffer in old code. (but my memory could be wrong)
Anyway, I understand the difference, but interrelation what implicit_flush directive should do was different. My last commit should make everyone happy, since it ignores PG(implicit_flush). -- Yasuo Ohgaki James Moore wrote: >>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
