Re: [PHP-DEV] Error handling brainstorming
You are either purposefully exaggerating or not doing it right.
if(fileop1() && fileop2() && fileop3()) {
// do valid stuff
} else {
// do error stuff
}
It's not that hard.
I guess it was my mistake that I simplified my actual code for simplicity's
sake. Please show me how would my actual code look stuffed in an "if"
statement:
try {
$cacheBaseFile = Core\CACHE_PATH . '/Compiled/' . \str_replace('\\', '-',
$symbolName);
// The validator checks whether the cache is fresh.
$cacheIsFresh = include $cacheFileBase . '.val.php';
// Attempt to load the cache (it should be there if the validator is
there, unless someone messed with the files).
if ($cacheIsFresh) {
$result = include $cacheFileBase . '.main.php';
} else {
$this->generateCache($symbolName);
...
}
return $result;
} catch (IncludeIOError $e) { // One or more of the files were damaged or
missing.
...
}
When you have:
1) comments
2) multiple statements
3) assign variables
4) call functions/methods with long arguments
etc.
...you can't just stuff it in an if (op() && op() && op()) and pretend this
is in any way a maintainable code style.
With exceptions:
try {
fileop1();
fileop2();
fileop3();
normal_actions();
} catch (IOException $e) {
exceptional_actions();
}
Now imagine fileop1 throws some other exception - note that you have no
idea which exceptions are there and nothing guarantees you fileop1
throws only IOException, and by the proposal here, any problem in any
code whatsoever results in exception now, even if the problem was in
converting log message to utf-8 while writing some log inside some
function called by fileop2(). Now your whole app has failed, even though
you don't really care about that log message at all.
Exceptions aren't about log messages, they're about exceptions - error
conditions that have to be handled.
If my code above generates another type of exception there are only two
options:
1) Either I catch that exception because I know how to handle it -or-
2) I don't catch it, and the app should correctly stop right there before
data damage is done.
I know PHP's model is all messed up, but no one here, I believe, is asking
about putting non-error log messages in Exceptions. IO failure is an
exception.
If your IO operation fails, you can't just log it and plow forward
blissfully without handling the problem.
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
Hi!
> Have you stopped for a moment to think this opinion through? Look at two
Of course not. Why would I bother thinking? It is always safe to assume
nobody thinks before writing anything to the list.
> typical patterns of error handling. The examples below are generalized from
> my file cache code. Having no cache is exceptional, because 99.999% of the
> time I run this, there is cache, except the first time when there's not.
>
> Tell me again how you using try..catch is very verbose and how you need to
> supply multiple catch blocks for "every kind of exception possible"?
You are either purposefully exaggerating or not doing it right.
if(fileop1() && fileop2() && fileop3()) {
// do valid stuff
} else {
// do error stuff
}
It's not that hard.
> With exceptions:
>
> try {
> fileop1();
> fileop2();
> fileop3();
> normal_actions();
> } catch (IOException $e) {
> exceptional_actions();
> }
Now imagine fileop1 throws some other exception - note that you have no
idea which exceptions are there and nothing guarantees you fileop1
throws only IOException, and by the proposal here, any problem in any
code whatsoever results in exception now, even if the problem was in
converting log message to utf-8 while writing some log inside some
function called by fileop2(). Now your whole app has failed, even though
you don't really care about that log message at all.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error handling brainstorming
The overall mood seems to be that since PHP has an error handler, everyone is free to handle errors any way they want. Everyone is surprisingly ignoring the two giant holes in that theory: 1) PHP Errors come with a severity code and a string message. You want to handle specific errors in a specific way? You better start writing giant regexes parsing the string messages. 2) When everyone starts handling errors in their own way with error handlers, you can't reliably use third party code. You are in your own universe. Stan
Re: [PHP-DEV] Error handling brainstorming
Hi!
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on every kind of
exception possible.
Have you stopped for a moment to think this opinion through? Look at two
typical patterns of error handling. The examples below are generalized from
my file cache code. Having no cache is exceptional, because 99.999% of the
time I run this, there is cache, except the first time when there's not.
Tell me again how you using try..catch is very verbose and how you need to
supply multiple catch blocks for "every kind of exception possible"?
With exceptions:
try {
fileop1();
fileop2();
fileop3();
normal_actions();
} catch (IOException $e) {
exceptional_actions();
}
Without exceptions:
$valid = true;
if (fileop1() !== FALSE) {
$valid = false;
}
if ($valid && fileop2() !== FALSE) {
$valid = false;
}
if ($valid && fileop3() !== FALSE) {
$valid = false;
}
if ($valid) {
normal_actions();
} else {
exceptional_actions();
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] Generators in PHP
On 2012-08-09 08:42, Nikita Popov wrote: Without parenthesis their behavior in array definitions and nested yields is ambigous: array(yield $key => $value) // can be either array((yield $key) => $value) // or array((yield $key => $value)) yield yield $key => $value; // can be either yield (yield $key) => $value; // or yield (yield $key => $value); Apart from that particular case there is the general operator precedence inclarity, e.g. yield $foo . $bar; // could be (yield $foo) . $bar; // or yield ($foo . $bar); Is this complicating yield a bit too much? All these ambiguities would go away if 'yield' had the same grammatical status as 'return' - in other words, if it were treated as a control-flow keyword rather than as an operator. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] Re: Generators in PHP
On 2012-08-09 14:25, Larry Garfield wrote:
On 07/27/2012 07:23 AM, Lester Caine wrote:
Nikita - I am looking for a well reasoned argument as to why generator
has to be added at all! 'Just because it can be' is not a valid
argument, but perhaps you could add to the RFC the performance
implication or advantage of what is being proposed. That would at
least be some comparison with the current methods of doing the same
thing?
Anthony had a very good writeup on generators and how they compare to
iterators last week:
http://blog.ircmaxell.com/2012/07/what-generators-can-do-for-you.html
I think that does a good job of laying out the case for generators as
"low-effort iterators".
I for one am lazy, and would much prefer writing:
to
first = $first;
$this->second = $second;
}
public function rewind()
{
$this->first->rewind();
$this->second->rewind();
$this->state = 0;
}
public function current()
{
return $this->_current;
}
public function key()
{
return $this->_key;
}
public function next()
{
switch($this->_state)
{
case -1:
return;
case 0:
$this->first->rewind();
$this->_state = 1;
case 1:
if($this->first->valid())
{
$this->_current = $this->first->current();
$this->_key = $this->first->key();
$this->first->next();
return;
}
else
{
$this->second->rewind();
$this->_state = 2;
}
case 2:
if($this->second->valid())
{
$this->_current = $this->second->current();
$this->_key = $this->second->key();
$this->second->next();
return;
}
else
{
$this->_state = -1;
return;
}
}
}
public function valid()
{
return $this->_state != -1;
}
}
?>
One question, though: It looks based on the voting like finally {}
blocks are going in. So... what should happen in the following situation:
function stuff() {
try {
foreach (range(1, 100) as $i) {
yield $i;
}
}
finally {
print "All done";
}
}
Does "All done" get printed once, or 101 times? Similarly:
function things() {
$i = 1;
try {
while (true) {
yield $i++;
}
}
finally {
print "All done";
}
}
That will run indefinitely. So will "All done" ever print, or does that
finally become unreachable?
My own gut expectation (the answers that would surprise me the least)
would be (a) once (because the foreach is _inside_ the try block, and
the catch/finally handler is hence _outside_ the loop); and (b) the
finally{} is unreachable (assuming that loop doesn't manage to throw an
exception!) because control flow never gets to the end of the try block.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
>
> One question, though: It looks based on the voting like finally {} blocks
> are going in. So... what should happen in the following situation:
>
> function stuff() {
> try {
> foreach (range(1, 100) as $i) {
> yield $i;
> }
> }
> finally {
> print "All done";
> }
> }
>
> Does "All done" get printed once, or 101 times? Similarly:
>
> function things() {
> $i = 1;
> try {
> while (true) {
> yield $i++;
> }
> }
> finally {
> print "All done";
> }
> }
>
> That will run indefinitely. So will "All done" ever print, or does that
> finally become unreachable?
>
> (I have no clue what the behavior "should" be in these cases, just that it
> should be sorted out sooner rather than later.)
>
Based on my understanding of both RFCs, I don't see that this would be
a conflict or lead to unexpected behavior. As stated by the generators
RFC: "When you first call the generator function ($lines =
getLinesFromFile($fileName)) the passed argument is bound, but nothing
of the code is actually executed. Instead the function directly
returns a Generator object.".
So in the event we are calling the function stuff(), nothing should
actually be executed, and as we iterate over the traversable object
the generator should be "passing control back and forth between the
generator and the calling code". This would be indicated by the
"yield" keyword present in the function. Meaning you should see the
expected result and finally should only ever be called once in your
first example.
As for you second example... Obviously if you've created an infinite
loop you've made everything outside of the loop unreachable, whether
you're using generators or not.
However, I'll let the author of the RFC provide any clarification or
corrections where I might be wrong.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Generators in PHP
On 07/27/2012 07:23 AM, Lester Caine wrote:
Nikita Popov wrote:
I'll ask again since no one has answered ...
>
>In a different way ...
>Is the only thing that changes the 'function' into a 'generator'
replacing
>the call to process the data with 'yield'? ( That would be
'SUSPEND' in an
>SQL procedure ) ...
>
>So how DOES an IDE work out the flow in order to correctly check that
>variables are defined?
>
>As always, my IDE provides a lot of 'sexy' stuff so that I don't
need to
>have it built in to the language, and I still can't see how a lot
of what is
>being loaded in helps with performance which is the only thing that
I am
>interested in. Performance wise why is yield better than just directly
>calling a function to handle the data?
Lester Caine and Alex Aulbach,
may I ask you to continue this discussion in a separate thread? I am
really interested in constructive responses about the generator RFC,
but your discussion is generating a lot of noise, which makes it very
hard for me to pick out the few mails that are of interest to me.
If you could open a new thread (like "Generator keyword") it would
help a lot.
Nikita - I am looking for a well reasoned argument as to why generator
has to be added at all! 'Just because it can be' is not a valid
argument, but perhaps you could add to the RFC the performance
implication or advantage of what is being proposed. That would at
least be some comparison with the current methods of doing the same
thing?
Anthony had a very good writeup on generators and how they compare to
iterators last week:
http://blog.ircmaxell.com/2012/07/what-generators-can-do-for-you.html
I think that does a good job of laying out the case for generators as
"low-effort iterators".
I still think the syntax feels clunky to me, but that's probably because
I'm not used to it from other languages.
One question, though: It looks based on the voting like finally {}
blocks are going in. So... what should happen in the following situation:
function stuff() {
try {
foreach (range(1, 100) as $i) {
yield $i;
}
}
finally {
print "All done";
}
}
Does "All done" get printed once, or 101 times? Similarly:
function things() {
$i = 1;
try {
while (true) {
yield $i++;
}
}
finally {
print "All done";
}
}
That will run indefinitely. So will "All done" ever print, or does that
finally become unreachable?
(I have no clue what the behavior "should" be in these cases, just that
it should be sorted out sooner rather than later.)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On 08/08/12 21:43, Stas Malyshev wrote:
Hi!
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires parentheses around? All these complex parentheses rules seem
unnecessarily complicated. I'd rather do it in a more simple way: yield
in an expression means incoming yield. I.e.:
$data = yield;
foo(yield, 1, 2);
list($a, $b) = yield;
Same with:
call(yield $value) - what is the meaning of $value here? Why not just
call(yield)?
I would also not support array((yield $key => $value)) - it seems to be
really unclear how it works. I'd just have yield produce a value which
was sent, and that's it, and you could use this value in the same way
you'd use any other expression.
Only question I have here is what happens if you use yield in the middle
of function call expression, for example:
call(foo(bar(), $foo, yield, 3), baz());
We are kind of stopping the function in the middle of the function call
and going to unrelated code here, and may never return back. Where the
required cleanups, etc. should happen?
Another question is, if my function is like this:
function foo()
{
var_dump(yield);
}
And I do: foo()->current() - what happens? Do I get null there? What
happens if after that I do send() on the same generator? In general,
interaction between incoming and outgoing yields is not very clear,
especially what happens when you combine them.
Also, small point: yield is repeatably called "statement" in the doc,
but in fact it can be both statement and expression with returning yield.
Hmm. This is just a quick thought:
Considering the yield syntax will vary about needing () round it, why
not make it a "fake" function (language construct).
This way it's consistent: yield(), yield($v), yield($k => $v), $a =
yield(), etc.
(yield $x) is just messy as an expression. We don't have (isset $x), we
have isset($x).
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
Hi!
> https://wiki.php.net/rfc/generators#yield_keyword
> https://wiki.php.net/rfc/generators#sending_values
I'm not sure $data = (yield $value) makes a lot of sense. Why we have
two variables here? Why it is only operator in the language that
requires parentheses around? All these complex parentheses rules seem
unnecessarily complicated. I'd rather do it in a more simple way: yield
in an expression means incoming yield. I.e.:
$data = yield;
foo(yield, 1, 2);
list($a, $b) = yield;
Same with:
call(yield $value) - what is the meaning of $value here? Why not just
call(yield)?
I would also not support array((yield $key => $value)) - it seems to be
really unclear how it works. I'd just have yield produce a value which
was sent, and that's it, and you could use this value in the same way
you'd use any other expression.
Only question I have here is what happens if you use yield in the middle
of function call expression, for example:
call(foo(bar(), $foo, yield, 3), baz());
We are kind of stopping the function in the middle of the function call
and going to unrelated code here, and may never return back. Where the
required cleanups, etc. should happen?
Another question is, if my function is like this:
function foo()
{
var_dump(yield);
}
And I do: foo()->current() - what happens? Do I get null there? What
happens if after that I do send() on the same generator? In general,
interaction between incoming and outgoing yields is not very clear,
especially what happens when you combine them.
Also, small point: yield is repeatably called "statement" in the doc,
but in fact it can be both statement and expression with returning yield.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Wed, Aug 8, 2012 at 10:27 PM, Andrew Faulds wrote:
> Hi Nikita,
>
> I notice you require brackets round yield $k => $v and yield $v. Is this the
> formal syntax, i.e. '(' T_YIELD var => var ')'? If so it makes sense in a
> way, but it feels a little hackish. Does yield $v cause some sort of parsing
> issue that putting it in brackets solves? I realise that it's less
> ambiguous, but I don't like the idea of it. PHP's syntax has enough special
> cases already IMO.
Without parenthesis their behavior in array definitions and nested
yields is ambigous:
array(yield $key => $value)
// can be either
array((yield $key) => $value)
// or
array((yield $key => $value))
yield yield $key => $value;
// can be either
yield (yield $key) => $value;
// or
yield (yield $key => $value);
Apart from that particular case there is the general operator
precedence inclarity, e.g.
yield $foo . $bar;
// could be
(yield $foo) . $bar;
// or
yield ($foo . $bar);
This obviously is not a problem per-se, but with yield-style unary
operators the precedence rules are often hard to figure out. E.g. most
people would probably think that
if (include('foo.php') == true) { ... }
would be check the return value of include, but it's actually not.
Rather it includes the file ('foo.php') == true, which is ''.
Another issue was a purely implementational: In order to support
by-ref yielding I have to distinguish between variable and
non-variable expressions, which breaks the usual precedence rules. I
was not able to fix the shift/reduce conflicts that are created by
this without requiring the parenthesis.
Also I'd like to mention that Python also has the paren-requirement
for yield-expressions. It even requires parens for a simple yield,
i.e. you'd have to write "data = (yield)". This is not necessary in
PHP, because PHP has semicolons.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On 08/08/12 21:14, Nikita Popov wrote:
On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov wrote:
5. Are multiple yields allowed? I.e. the rfc mentions something like
yield yield $a - what that would mean? I'd allow yield only be applied
to variable expression (lval) because double yield doesn't make sense to
me, but maybe I miss something.
yield yield $a would basically first yield $a and then receive some
value (via send) and yield that value again. Nothing you'd normally do
;) It was mentioned only as a syntax ambiguity consideration.
Actually I added some additional parenthesis requirements for yield.
For example you'd have to write the above as `yield (yield $a)` now
(which should be slightly more clear). I haven't yet reflected this
change in the RFC, but I'll add a section on it later.
6. “Sending values” section seems to be missing. Especially useful would
be to cover what happens with keys there and what is the syntax there -
is it just "$a = yield;"? Or does it mean when yield is used in
expression it becomes incoming yield? And, last but not least - do we
need sending into generators at all?
Yeah, I haven't written that section yet. But it is fairly simple: If
you go $generator->send($foo) then $foo will be the result of the
current `yield` expression. And yes, this also works with keys and
values. All of the following are valid:
$data = yield;
$data = (yield $value);
$data = (yield $key => $value);
The first case is the most common though. I.e. you usually use it
either as a generator or a reverse generator, not both. But doing both
is also common for cooperative multitasking etc.
Regarding the last question: I think the feature is worth adding. It
is a very powerful concept that is hard to implement otherwise. Useful
in particular for things like parsing and multitasking.
6. What happens if you send into a by-ref generator? Is the data sent
by-ref then? What if it's an expression that can't be send by-ref?
No, sending is always by-value. By-ref only affects the yielding part.
I now added the mentioned sections:
https://wiki.php.net/rfc/generators#yield_keyword
https://wiki.php.net/rfc/generators#sending_values
I also added a list of error conditions:
https://wiki.php.net/rfc/generators#error_conditions
Sorry for the delay,
Nikita
Hi Nikita,
I notice you require brackets round yield $k => $v and yield $v. Is this
the formal syntax, i.e. '(' T_YIELD var => var ')'? If so it makes sense
in a way, but it feels a little hackish. Does yield $v cause some sort
of parsing issue that putting it in brackets solves? I realise that it's
less ambiguous, but I don't like the idea of it. PHP's syntax has enough
special cases already IMO.
Regards,
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Generators in PHP
On Fri, Jul 27, 2012 at 8:09 PM, Nikita Popov wrote: >> 5. Are multiple yields allowed? I.e. the rfc mentions something like >> yield yield $a - what that would mean? I'd allow yield only be applied >> to variable expression (lval) because double yield doesn't make sense to >> me, but maybe I miss something. > > yield yield $a would basically first yield $a and then receive some > value (via send) and yield that value again. Nothing you'd normally do > ;) It was mentioned only as a syntax ambiguity consideration. > > Actually I added some additional parenthesis requirements for yield. > For example you'd have to write the above as `yield (yield $a)` now > (which should be slightly more clear). I haven't yet reflected this > change in the RFC, but I'll add a section on it later. > >> 6. “Sending values” section seems to be missing. Especially useful would >> be to cover what happens with keys there and what is the syntax there - >> is it just "$a = yield;"? Or does it mean when yield is used in >> expression it becomes incoming yield? And, last but not least - do we >> need sending into generators at all? > > Yeah, I haven't written that section yet. But it is fairly simple: If > you go $generator->send($foo) then $foo will be the result of the > current `yield` expression. And yes, this also works with keys and > values. All of the following are valid: > > $data = yield; > $data = (yield $value); > $data = (yield $key => $value); > > The first case is the most common though. I.e. you usually use it > either as a generator or a reverse generator, not both. But doing both > is also common for cooperative multitasking etc. > > Regarding the last question: I think the feature is worth adding. It > is a very powerful concept that is hard to implement otherwise. Useful > in particular for things like parsing and multitasking. > >> 6. What happens if you send into a by-ref generator? Is the data sent >> by-ref then? What if it's an expression that can't be send by-ref? > > No, sending is always by-value. By-ref only affects the yielding part. I now added the mentioned sections: https://wiki.php.net/rfc/generators#yield_keyword https://wiki.php.net/rfc/generators#sending_values I also added a list of error conditions: https://wiki.php.net/rfc/generators#error_conditions Sorry for the delay, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix per-module logging in apache 2.4
El 08/08/12 15:38, Pierre Joye escribió: > hi Chirstian! > > Could you please either (or both :) open a bug and attach the patch to > it or create a pull request please? I opened a pull request a few minutes ago., https://github.com/php/php-src/pull/154 Cheers ! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix per-module logging in apache 2.4
hi Chirstian!
Could you please either (or both :) open a bug and attach the patch to
it or create a pull request please?
Thanks for your work!
Cheers,
On Mon, Aug 6, 2012 at 11:59 PM, Cristian Rodríguez
wrote:
> ---
> sapi/apache2filter/sapi_apache2.c |3 +++
> sapi/apache2handler/mod_php5.c|4
> 2 files changed, 7 insertions(+)
>
> diff --git a/sapi/apache2filter/sapi_apache2.c
> b/sapi/apache2filter/sapi_apache2.c
> index 0b51cfb..a8fec5c 100644
> --- a/sapi/apache2filter/sapi_apache2.c
> +++ b/sapi/apache2filter/sapi_apache2.c
> @@ -744,6 +744,9 @@ static size_t php_apache_fsizer_stream(void *handle
> TSRMLS_DC)
> return 0;
> }
>
> +#ifdef APLOG_USE_MODULE
> +APLOG_USE_MODULE(php5);
> +#endif
> AP_MODULE_DECLARE_DATA module php5_module = {
> STANDARD20_MODULE_STUFF,
> create_php_config, /* create per-directory config
> structure */
> diff --git a/sapi/apache2handler/mod_php5.c b/sapi/apache2handler/mod_php5.c
> index 9df4f25..35d5548 100644
> --- a/sapi/apache2handler/mod_php5.c
> +++ b/sapi/apache2handler/mod_php5.c
> @@ -25,6 +25,10 @@
> #include "php.h"
> #include "php_apache.h"
>
> +#ifdef APLOG_USE_MODULE
> +APLOG_USE_MODULE(php5);
> +#endif
> +
> AP_MODULE_DECLARE_DATA module php5_module = {
> STANDARD20_MODULE_STUFF,
> create_php_config, /* create per-directory config
> structure */
> --
> 1.7.10.4
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
Pierre
@pierrejoye | 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] [PATCH] sapi/apache2*: Use ap_state_query where possible instead of old method of creating a pool userdata entry.
On 08/08/2012 10:33 AM, Cristian Rodríguez wrote: sapi/apache2filter/sapi_apache2.c | 11 +-- sapi/apache2handler/sapi_apache2.c | 12 ++-- 2 files changed, 19 insertions(+), 4 deletions(-) Patches to the mail list are very likely to get lost. It's probably better to attach them to a bug at https://bugs.php.net and/or do a pull request at https://github.com/php/php-src Since there wasn't any response to your previous patch, you will likely also need to follow up to ensure the code gets merged or rejected. Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] sapi/apache2*: Use ap_state_query where possible instead of old method of creating a pool userdata entry.
---
sapi/apache2filter/sapi_apache2.c | 11 +--
sapi/apache2handler/sapi_apache2.c | 12 ++--
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/sapi/apache2filter/sapi_apache2.c
b/sapi/apache2filter/sapi_apache2.c
index a8fec5c..21f2fa3 100644
--- a/sapi/apache2filter/sapi_apache2.c
+++ b/sapi/apache2filter/sapi_apache2.c
@@ -606,11 +606,17 @@ static int
php_apache_server_startup(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp, server_rec *s)
{
+
+#if AP_MODULE_MAGIC_AT_LEAST(20110203,1)
+/* Apache will load, unload and then reload a DSO module. This
+ * prevents us from starting PHP until the second load. */
+ if (ap_state_query(AP_SQ_MAIN_STATE) == AP_SQ_MS_CREATE_PRE_CONFIG) {
+return OK;
+ }
+#else
void *data = NULL;
const char *userdata_key = "apache2filter_post_config";
- /* Apache will load, unload and then reload a DSO module. This
-* prevents us from starting PHP until the second load. */
apr_pool_userdata_get(&data, userdata_key, s->process->pool);
if (data == NULL) {
/* We must use set() here and *not* setn(), otherwise the
@@ -622,6 +628,7 @@ php_apache_server_startup(apr_pool_t *pconf, apr_pool_t
*plog,
apr_pool_cleanup_null, s->process->pool);
return OK;
}
+#endif
/* Set up our overridden path. */
if (apache2_php_ini_path_override) {
diff --git a/sapi/apache2handler/sapi_apache2.c
b/sapi/apache2handler/sapi_apache2.c
index 900a3a4..a578740 100644
--- a/sapi/apache2handler/sapi_apache2.c
+++ b/sapi/apache2handler/sapi_apache2.c
@@ -430,12 +430,19 @@ static int php_pre_config(apr_pool_t *pconf, apr_pool_t
*plog, apr_pool_t *ptemp
static int
php_apache_server_startup(apr_pool_t *pconf, apr_pool_t *plog, apr_pool_t
*ptemp, server_rec *s)
{
- void *data = NULL;
- const char *userdata_key = "apache2hook_post_config";
+#if AP_MODULE_MAGIC_AT_LEAST(20110203,1)
/* Apache will load, unload and then reload a DSO module. This
* prevents us from starting PHP until the second load. */
+if (ap_state_query(AP_SQ_MAIN_STATE) == AP_SQ_MS_CREATE_PRE_CONFIG) {
+ return OK;
+}
+#else
+ void *data = NULL;
+ const char *userdata_key = "apache2hook_post_config";
+
apr_pool_userdata_get(&data, userdata_key, s->process->pool);
+
if (data == NULL) {
/* We must use set() here and *not* setn(), otherwise the
* static string pointed to by userdata_key will be mapped
@@ -445,6 +452,7 @@ php_apache_server_startup(apr_pool_t *pconf, apr_pool_t
*plog, apr_pool_t *ptemp
apr_pool_userdata_set((const void *)1, userdata_key,
apr_pool_cleanup_null, s->process->pool);
return OK;
}
+#endif
/* Set up our overridden path. */
if (apache2_php_ini_path_override) {
--
1.7.10.4
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
