Oops. s/interrelation/interpretation/
Yasuo Ohgaki wrote: > 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
