Re: [PHP-DEV] post 5.3.0 development
On 26.06.2009, at 17:26, Lukas Kahwe Smith wrote: After this period bug fixes can be applied again. However feature additions should wait until after 5.3.1, which we expect to be released within a month or two. As always if you are unsure, ask Johannes. And also as always if there is a solid reason, common sense rules, but please do ask first. Ok, so we are in the process of announcing 5.3.0. So you can now go ahead and commit bug fixes without prior review into 5_3. Please hold off from feature additions for now or bring them up on internals if you feel they are urgent. I will start notifying developer about bug fixes that should be merged now. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
2009/6/27 Johannes Schlüter johan...@php.net: On Fri, 2009-06-26 at 20:40 -0400, Ilia Alshanetsky wrote: After some conversations with Rasmus on IRC i've come up with the following patch: http://ilia.ws/patch/curl.txt I this the latest patch and all agree t it? Or were there further improvements? Could somebody of you please commit it then to 5.3 thanks. done (5.2/3, 6) -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Hi, On Fri, 2009-06-26 at 18:30 +0100, Scott MacVicar wrote: This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. In my experience - from projects I participated as well were I just observed - release branches with CVS often end with more pain than freezes. It is of course hard to predict what would happen in this project with these developers in this situation. And well, as said 5.3 is a quite big release and has many things where errors can be introduced and I guess we all want it out soonish as stable as possible ... We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. HEAD is the development branch. 5.3 should only get stable stuff anyways. And I assume you are committing only well tested stuff to 5.3 which means you have some way of management outside CVS assisting you during development and testing of your stuff. About the extension of the freeze for the migration: I think we first should have a window for getting some fixes in before doing the migration so at least some of the backlog can be cleared. As far as I know there's n final complete migration plan and there might be people who want to play a little with the test repo once 5.3 is out. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On Fri, 2009-06-26 at 20:40 -0400, Ilia Alshanetsky wrote: After some conversations with Rasmus on IRC i've come up with the following patch: http://ilia.ws/patch/curl.txt I this the latest patch and all agree t it? Or were there further improvements? Could somebody of you please commit it then to 5.3 thanks. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On 26-Jun-09, at 1:30 PM, Scott MacVicar wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. +1 A long term freeze will simply mean that some bug fixes will be missed in the 5.3 release and we'd end up with a less stable version in the long term. I know it makes release cycle that much simpler, but lets make sure we don't stall the development. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On Fri, Jun 26, 2009 at 17:26, Lukas Kahwe Smithm...@pooteeweet.org wrote: We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. And the move to SVN? It'll require a complete cvs.php.net freeze for couple of days, I think? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [SVN-MIGRATION] Re: [PHP-DEV] post 5.3.0 development
On Jun 26, 2009, at 2:22 PM, Hannes Magnusson wrote: We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. And the move to SVN? It'll require a complete cvs.php.net freeze for couple of days, I think? Yes, but it's not ready for that yet; an unfreeze after 5.3's release won't kill anyway. But keep in mind that the SVN freeze will freeze PEAR and PECL and GTK and... well, everyone. Once CVS write access is shut off, it'll never be turned back on (unless there's a problem with SVN). Whereas this freeze is just on PHP itself. -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On 26.06.2009, at 20:26, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Lukas Kahwe Smith wrote: Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. Keep an eye on http://bugs.php.net/48518 I don't think we can let 5.3 out the door with this regression. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorfras...@lerdorf.com wrote: Lukas Kahwe Smith wrote: Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. Keep an eye on http://bugs.php.net/48518 I don't think we can let 5.3 out the door with this regression. btw, 5.2.10 is out too with this regression. If I'm not mistaken. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Pierre Joye wrote: On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorfras...@lerdorf.com wrote: Lukas Kahwe Smith wrote: Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. Keep an eye on http://bugs.php.net/48518 I don't think we can let 5.3 out the door with this regression. btw, 5.2.10 is out too with this regression. If I'm not mistaken. It is, and it is causing some nasty headaches because it is non-trivial to debug. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: On 26.06.2009, at 20:26, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. If we're freezing some more after this release for the SVN conversion then we could have a pretty cold branch for another week or so. As I've already said, I agree with only allow verified bug fixes by Johannes into 5.3.0. it's this extra bureaucracy that is getting added on top that's sucking hard. I don't want to leave it up to someone else to merge it into 5.3, I should be doing it myself. It's possible that things could get accidentally missed wen someone else is applying it. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Scott MacVicar wrote: If we're freezing some more after this release for the SVN conversion then we could have a pretty cold branch for another week or so. As I've already said, I agree with only allow verified bug fixes by Johannes into 5.3.0. it's this extra bureaucracy that is getting added on top that's sucking hard. I don't want to leave it up to someone else to merge it into 5.3, I should be doing it myself. It's possible that things could get accidentally missed wen someone else is applying it. I completely agree, which is why the solution is: 1) commit to HEAD 2) send a message to internals CC lukas with a link to the commit message 3) after the freeze is over, Lukas forwards your message back to you, and you do the merge. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
you totally misunderstood the mail. The freeze is about the days between now and the release itself on Tuesday (monday evening actually). That's perfectly valid. The idea then is to allow only bug fixes in 5.3.1, and only bug fixes. What's wrong with that? -- Pierre On Fri, Jun 26, 2009 at 9:26 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: On 26.06.2009, at 20:26, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. If we're freezing some more after this release for the SVN conversion then we could have a pretty cold branch for another week or so. As I've already said, I agree with only allow verified bug fixes by Johannes into 5.3.0. it's this extra bureaucracy that is getting added on top that's sucking hard. I don't want to leave it up to someone else to merge it into 5.3, I should be doing it myself. It's possible that things could get accidentally missed wen someone else is applying it. Scott -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
I *completely* agree with making sure 5.3.0 is stable and stopping extra things sneaking their way in. I just don't like the way that it is being done. If the release is tagged and built, then why continue with the freeze? Why not open it up for bug fixes towards 5.3.1? If the reason that you're about to be given is, we might find something critical and need to re-roll 5.3.0 then branch from the tag you've created, fix what's needed and re-tag. Even though CVS sucks it does allow this. This is the way the Mozilla project has done it for years, following their example we'd just create a PHP_5_3_RELBRANCH and work from that. The RMs are the only ones that get to decide what goes in after the freeze. https://wiki.mozilla.org/SeaMonkey:Release_Process Scott On 26 Jun 2009, at 21:12, Pierre Joye wrote: you totally misunderstood the mail. The freeze is about the days between now and the release itself on Tuesday (monday evening actually). That's perfectly valid. The idea then is to allow only bug fixes in 5.3.1, and only bug fixes. What's wrong with that? -- Pierre On Fri, Jun 26, 2009 at 9:26 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: On 26.06.2009, at 20:26, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. If we're freezing some more after this release for the SVN conversion then we could have a pretty cold branch for another week or so. As I've already said, I agree with only allow verified bug fixes by Johannes into 5.3.0. it's this extra bureaucracy that is getting added on top that's sucking hard. I don't want to leave it up to someone else to merge it into 5.3, I should be doing it myself. It's possible that things could get accidentally missed wen someone else is applying it. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
this process is known and we already said that we have to change the way we do it after 5.3.0. On Fri, Jun 26, 2009 at 10:35 PM, Scott MacVicarsc...@macvicar.net wrote: I *completely* agree with making sure 5.3.0 is stable and stopping extra things sneaking their way in. I just don't like the way that it is being done. If the release is tagged and built, then why continue with the freeze? Why not open it up for bug fixes towards 5.3.1? If the reason that you're about to be given is, we might find something critical and need to re-roll 5.3.0 then branch from the tag you've created, fix what's needed and re-tag. Even though CVS sucks it does allow this. This is the way the Mozilla project has done it for years, following their example we'd just create a PHP_5_3_RELBRANCH and work from that. The RMs are the only ones that get to decide what goes in after the freeze. https://wiki.mozilla.org/SeaMonkey:Release_Process Scott On 26 Jun 2009, at 21:12, Pierre Joye wrote: you totally misunderstood the mail. The freeze is about the days between now and the release itself on Tuesday (monday evening actually). That's perfectly valid. The idea then is to allow only bug fixes in 5.3.1, and only bug fixes. What's wrong with that? -- Pierre On Fri, Jun 26, 2009 at 9:26 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 19:59, Lukas Kahwe Smith wrote: On 26.06.2009, at 20:26, Pierre Joye pierre@gmail.com wrote: On Fri, Jun 26, 2009 at 7:30 PM, Scott MacVicarsc...@macvicar.net wrote: On 26 Jun 2009, at 16:26, Lukas Kahwe Smith wrote: Aloha, So the last fix is just being prepared for a commit and so we will be tagging 5.3.0 soon. We would like to up hold the commit freeze until 5.3.0 is announced next Tuesday. This freeze that you guys have implemented is frustrating, just branch 5_3 into a release branch and Johannes can take selective fixes from 5_3 as needed. We all know your reasons for the freeze and agree with it but holding up regular development is a PITA. It is not holding up development. It is about getting a viable release cycle and to give us the minimum safety to release 5.3.1 in a reasonable time frame. Please explain me what's wrong to allow only bug fixes for this phase? Also please note that we have HEAD for all the developments and new features. Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. If we're freezing some more after this release for the SVN conversion then we could have a pretty cold branch for another week or so. As I've already said, I agree with only allow verified bug fixes by Johannes into 5.3.0. it's this extra bureaucracy that is getting added on top that's sucking hard. I don't want to leave it up to someone else to merge it into 5.3, I should be doing it myself. It's possible that things could get accidentally missed wen someone else is applying it. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
On Fri, Jun 26, 2009 at 22:35, Scott MacVicarsc...@macvicar.net wrote: If the reason that you're about to be given is, we might find something critical and need to re-roll 5.3.0 then branch from the tag you've created, fix what's needed and re-tag. Even though CVS sucks it does allow this. Fair enough. However. You should still be committing to HEAD before 5_whatever. And we are about to switch from SVN. Lets keep the release model as-is for 3more days, migrate to SVN and then design a better release model. -Hannes p.s. I missed the tagging by an hour, so I feel your frustration - but you should be developing in the developer branch, not release branch... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Pierre Joye wrote: On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorfras...@lerdorf.com wrote: Lukas Kahwe Smith wrote: Exactly. I will do my best to track things that need to be merged. Best is to note if something needs to be merged. But if you all feel it's such a huge burden then you can of course insist on putting the burden on the RMs. The fact of the matter is that our current infrastructure is not fit for providing both sides with an efficient solution. Keep an eye on http://bugs.php.net/48518 I don't think we can let 5.3 out the door with this regression. btw, 5.2.10 is out too with this regression. If I'm not mistaken. Ok, I am running out of time for this one today. As Tony mentioned in his original bug report for 48518: Simple patch fixes this problem, but there is another one to consider: should the refcount be decreased when closing the cURL handle? That would be a yes. I don't see an easy way to relate an open File-Handle resource back to the curl handle though short of walking all open file handles and checking them against the fps in the curl struct, or creating a separate llist for these resources tied to the curl handle. If someone has an idea for a clean fix here, please speak up. Second, because there was no addref on the fp before, a simple curl_exec($ch); fclose($fp); would force a flush and the data would be available in the file. Even if we decrement the refcount on the file handle resource in the curl handle destructor, that still doesn't bring us back to that behaviour because the fclose there doesn't actually close the file yet, as it shouldn't. So here, a secondary fix, and a side-effect of this issue, is that we should probably force a flush on the fclose for any flushable streams we try to close when there are outstanding references holding them open. I think doing both of these should take care of this one. And 10 years ago I'd be hacking on this for the next 3 hours, but right now I am spending the next 3 hours picking up Carl from Lego Camp and taking him to his piano lesson... -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Here is the least intrusive fix I can come up for this bug. When doing
curl_close() the dtor will force flush of data on a file stream
synching the data to disk. As far as I can tell (using Rasmus'
example) this appears to adequately fix the problem and I see no
immediate side-effects.
Index: ext/curl/interface.c
===
RCS file: /repository/php-src/ext/curl/interface.c,v
retrieving revision 1.62.2.14.2.57
diff -u -p -a -d -r1.62.2.14.2.57 interface.c
--- ext/curl/interface.c15 Jun 2009 12:38:11 - 1.62.2.14.2.57
+++ ext/curl/interface.c26 Jun 2009 23:50:00 -
@@ -2093,6 +2093,11 @@ static void _php_curl_close_ex(php_curl
efree(ch-header.str);
}
+ /* flush the file handle, so any remaining data is synched to disk */
+ if (ch-handlers-write-method = PHP_CURL_FILE
ch-handlers-write-fp) {
+ fflush(ch-handlers-write-fp);
+ }
+
efree(ch-handlers-write);
efree(ch-handlers-write_header);
efree(ch-handlers-read);
Ilia Alshanetsky
On 26-Jun-09, at 6:02 PM, Rasmus Lerdorf wrote:
Pierre Joye wrote:
On Fri, Jun 26, 2009 at 9:11 PM, Rasmus Lerdorfras...@lerdorf.com
wrote:
Lukas Kahwe Smith wrote:
Exactly.
I will do my best to track things that need to be merged. Best is
to
note if something needs to be merged.
But if you all feel it's such a huge burden then you can of course
insist on putting the burden on the RMs. The fact of the matter
is that
our current infrastructure is not fit for providing both sides
with an
efficient solution.
Keep an eye on http://bugs.php.net/48518
I don't think we can let 5.3 out the door with this regression.
btw, 5.2.10 is out too with this regression. If I'm not mistaken.
Ok, I am running out of time for this one today.
As Tony mentioned in his original bug report for 48518:
Simple patch fixes this problem, but there is another one to
consider:
should the refcount be decreased when closing the cURL handle?
That would be a yes. I don't see an easy way to relate an open
File-Handle resource back to the curl handle though short of walking
all
open file handles and checking them against the fps in the curl
struct,
or creating a separate llist for these resources tied to the curl
handle. If someone has an idea for a clean fix here, please speak up.
Second, because there was no addref on the fp before, a simple
curl_exec($ch);
fclose($fp);
would force a flush and the data would be available in the file. Even
if we decrement the refcount on the file handle resource in the curl
handle destructor, that still doesn't bring us back to that behaviour
because the fclose there doesn't actually close the file yet, as it
shouldn't. So here, a secondary fix, and a side-effect of this issue,
is that we should probably force a flush on the fclose for any
flushable
streams we try to close when there are outstanding references holding
them open.
I think doing both of these should take care of this one.
And 10 years ago I'd be hacking on this for the next 3 hours, but
right
now I am spending the next 3 hours picking up Carl from Lego Camp and
taking him to his piano lesson...
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
You have an assignment instead of a comparison there. Scott On 27 Jun 2009, at 00:52, Ilia Alshanetsky wrote: curl.txt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Thanks Scott, it helps to save files before quitting ;-)
Here is the updated patch.
Ilia Alshanetsky
Index: ext/curl/interface.c
===
RCS file: /repository/php-src/ext/curl/interface.c,v
retrieving revision 1.62.2.14.2.57
diff -u -p -a -d -r1.62.2.14.2.57 interface.c
--- ext/curl/interface.c15 Jun 2009 12:38:11 - 1.62.2.14.2.57
+++ ext/curl/interface.c26 Jun 2009 23:57:30 -
@@ -2093,6 +2093,11 @@ static void _php_curl_close_ex(php_curl
efree(ch-header.str);
}
+ /* flush the file handle, so any remaining data is synched to disk */
+ if (ch-handlers-write-method == PHP_CURL_FILE
ch-handlers-write-fp) {
+ fflush(ch-handlers-write-fp);
+ }
+
efree(ch-handlers-write);
efree(ch-handlers-write_header);
efree(ch-handlers-read);
On 26-Jun-09, at 7:55 PM, Scott MacVicar wrote:
You have an assignment instead of a comparison there.
Scott
On 27 Jun 2009, at 00:52, Ilia Alshanetsky wrote:
curl.txt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Just to keep the list in synch with the irc discussion. I pointed out that this is only half of the fix. The refcount still prevents fclose from flushing the data, so if you do: $url = 'http://slowgeek.com/test.xml'; $cfile = 'out.xml'; $ch = curl_init($url); curl_setopt($ch, CURLOPT_FILE, $fp = fopen($cfile,'w')); $status = curl_exec($ch); fclose($fp); $data = file_get_contents($cfile); var_dump($data); // 0 bytes here curl_close($ch); $data = file_get_contents($cfile); var_dump($data); // full contents here I still think we need to look at doing a flush on an fclose which doesn't reach the stream destructor due to refcount issues. Can anybody think of any side-effects of a flush on a stream close? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
After some conversations with Rasmus on IRC i've come up with the following patch: http://ilia.ws/patch/curl.txt This basically forces flush() on the header output streams right after curl_exec(), this ensures that the data retrieved by curl is synched to disk. The patch is also self contained to curl so no external elements are affected by the patch. Ilia Alshanetsky On 26-Jun-09, at 8:24 PM, Rasmus Lerdorf wrote: Just to keep the list in synch with the irc discussion. I pointed out that this is only half of the fix. The refcount still prevents fclose from flushing the data, so if you do: $url = 'http://slowgeek.com/test.xml'; $cfile = 'out.xml'; $ch = curl_init($url); curl_setopt($ch, CURLOPT_FILE, $fp = fopen($cfile,'w')); $status = curl_exec($ch); fclose($fp); $data = file_get_contents($cfile); var_dump($data); // 0 bytes here curl_close($ch); $data = file_get_contents($cfile); var_dump($data); // full contents here I still think we need to look at doing a flush on an fclose which doesn't reach the stream destructor due to refcount issues. Can anybody think of any side-effects of a flush on a stream close? -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Ilia Alshanetsky wrote: After some conversations with Rasmus on IRC i've come up with the following patch: http://ilia.ws/patch/curl.txt This basically forces flush() on the header output streams right after curl_exec(), this ensures that the data retrieved by curl is synched to disk. The patch is also self contained to curl so no external elements are affected by the patch. This looks good to me. It means 5.2.9 code will keep working. The only slight behavioural change where the fp is now flushed before the fclose/curl_close, but if anybody relied on a read at that point not returning the last buffer, they deserve what they get. This needs to go into all branches and let's re-tag and re-package 5.3 with this, Andrei's calloc fix, and the UPGRADING fixes. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] post 5.3.0 development
Rasmus Lerdorf wrote: And 10 years ago I'd be hacking on this for the next 3 hours, but right now I am spending the next 3 hours picking up Carl from Lego Camp and taking him to his piano lesson... What, no cello lesson? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
