Good morning,
This is just a very small change, I propose this RFC for discussion to turn
the C function "gc_collect_cycles" into a pointer.
https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers fail
to capture the dynamics of GC and we need better hooks to make this
possible.
greetings
Benjamin
Hey:
Good morning,
This is just a very small change, I propose this RFC for discussion to turn
the C function "gc_collect_cycles" into a pointer.
yeah, this idea is better than add hardly getimeofday into gc
thanks
https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers fail
to capture the dynamics of GC and we need better hooks to make this
possible.greetings
Benjamin
--
Xinchen Hui
@Laruence
http://www.laruence.com/
Good morning,
This is just a very small change, I propose this RFC for discussion to turn
the C function "gc_collect_cycles" into a pointer.https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers fail
to capture the dynamics of GC and we need better hooks to make this
possible.
There are many other things that could be turned into function
pointers to allow extensions to hook.
Our hook strategy should be reviewed entirely.
Not only GC. If you look at streams, many of them are not
overwritable, and some are, but they are missing from the headers file
so you may not overwrite them.
I suggest we design a wider RFC for PHP7 about what we would be able
to hook, and what not (and what is the impact, because the more you
hook , the more complex it becomes about bad interactions).
This may also include a refactoring in the zend_module_entry and the
zend_extension structs. Fe, zend_extension hooks about the op_array
could be reworked , I find the op_array_dtor_handler hook misplaced in
the chain.
zend_module_entry could also benefit from refactoring to have a better
knowing of other extensions, and a true dependency manager.
Julien Pauli
On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:Good morning,
This is just a very small change, I propose this RFC for discussion to
turn
the C function "gc_collect_cycles" into a pointer.https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers fail
to capture the dynamics of GC and we need better hooks to make this
possible.There are many other things that could be turned into function
pointers to allow extensions to hook.
Our hook strategy should be reviewed entirely.Not only GC. If you look at streams, many of them are not
overwritable, and some are, but they are missing from the headers file
so you may not overwrite them.I suggest we design a wider RFC for PHP7 about what we would be able
to hook, and what not (and what is the impact, because the more you
hook , the more complex it becomes about bad interactions).This may also include a refactoring in the zend_module_entry and the
zend_extension structs. Fe, zend_extension hooks about the op_array
could be reworked , I find the op_array_dtor_handler hook misplaced in
the chain.
zend_module_entry could also benefit from refactoring to have a better
knowing of other extensions, and a true dependency manager.
That sounds like a lot of work.
+1 if somebody willing to champion that effort, but I wouldn't
delay/discard this small improvement on the vague promise that maybe this
will be solved as part of a bigger rfc.
just my 2 cents ofc.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:Good morning,
This is just a very small change, I propose this RFC for discussion to
turn
the C function "gc_collect_cycles" into a pointer.https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers
fail
to capture the dynamics of GC and we need better hooks to make this
possible.There are many other things that could be turned into function
pointers to allow extensions to hook.
Our hook strategy should be reviewed entirely.Not only GC. If you look at streams, many of them are not
overwritable, and some are, but they are missing from the headers file
so you may not overwrite them.I suggest we design a wider RFC for PHP7 about what we would be able
to hook, and what not (and what is the impact, because the more you
hook , the more complex it becomes about bad interactions).This may also include a refactoring in the zend_module_entry and the
zend_extension structs. Fe, zend_extension hooks about the op_array
could be reworked , I find the op_array_dtor_handler hook misplaced in
the chain.
zend_module_entry could also benefit from refactoring to have a better
knowing of other extensions, and a true dependency manager.That sounds like a lot of work.
+1 if somebody willing to champion that effort, but I wouldn't delay/discard
this small improvement on the vague promise that maybe this will be solved
as part of a bigger rfc.
just my 2 cents ofc.
Yep, but the problem in adding a new hook is that today its for
feature A, tomorrow it will be for feature B, etc...
There is a risk of lack of consistency between all the ideas, that's
why I myself did not propose any single idea in this way, but prefer
merging them and propose something more consistent.
We could benefit from a new major release to have a more global
hooking strategy.
Also, as this changes the ABI by publishing a new ZEND_API, we should
consider adding this in a major and not in a stable release (even
thought that doesnt break the ABI).
I agree some ideas may represent more work than others (like a
dependency management system for extensions), however, big part of the
ideas is just about "what hook to move", "where to", "why" and "what
hook to add" (and why).
Also, having too many hooks can lead to many problems like extensions
incompatibility, something barely taken care of in our module API, but
which should as well be redesigned as it doesn't really work that
much.
Julien.P
On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:Good morning,
This is just a very small change, I propose this RFC for discussion to
turn
the C function "gc_collect_cycles" into a pointer.https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers
fail
to capture the dynamics of GC and we need better hooks to make this
possible.There are many other things that could be turned into function
pointers to allow extensions to hook.
Our hook strategy should be reviewed entirely.Not only GC. If you look at streams, many of them are not
overwritable, and some are, but they are missing from the headers file
so you may not overwrite them.I suggest we design a wider RFC for PHP7 about what we would be able
to hook, and what not (and what is the impact, because the more you
hook , the more complex it becomes about bad interactions).This may also include a refactoring in the zend_module_entry and the
zend_extension structs. Fe, zend_extension hooks about the op_array
could be reworked , I find the op_array_dtor_handler hook misplaced in
the chain.
zend_module_entry could also benefit from refactoring to have a better
knowing of other extensions, and a true dependency manager.That sounds like a lot of work.
+1 if somebody willing to champion that effort, but I wouldn't delay/discard
this small improvement on the vague promise that maybe this will be solved
as part of a bigger rfc.
just my 2 cents ofc.Yep, but the problem in adding a new hook is that today its for
feature A, tomorrow it will be for feature B, etc...
There is a risk of lack of consistency between all the ideas, that's
why I myself did not propose any single idea in this way, but prefer
merging them and propose something more consistent.
We could benefit from a new major release to have a more global
hooking strategy.
Also, as this changes the ABI by publishing a new ZEND_API, we should
consider adding this in a major and not in a stable release (even
thought that doesnt break the ABI).I agree some ideas may represent more work than others (like a
dependency management system for extensions), however, big part of the
ideas is just about "what hook to move", "where to", "why" and "what
hook to add" (and why).Also, having too many hooks can lead to many problems like extensions
incompatibility, something barely taken care of in our module API, but
which should as well be redesigned as it doesn't really work that
much.Julien.P
For GC and any other function that would need to be overwritten, we
may use zend_utility_functions.
That would limit the number of exported symbols we publish.
I don't know why zend_execute and zend_execute_internal are not part
of it though.
That would need a refactor to export zend_utility_function as global,
and use it in any SAPI (it's actually local to main()).
Dmitry, Laruence , any advice ?
Julien.Pauli
On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:Good morning,
This is just a very small change, I propose this RFC for discussion to
turn
the C function "gc_collect_cycles" into a pointer.https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers
fail
to capture the dynamics of GC and we need better hooks to make this
possible.There are many other things that could be turned into function
pointers to allow extensions to hook.
Our hook strategy should be reviewed entirely.Not only GC. If you look at streams, many of them are not
overwritable, and some are, but they are missing from the headers file
so you may not overwrite them.I suggest we design a wider RFC for PHP7 about what we would be able
to hook, and what not (and what is the impact, because the more you
hook , the more complex it becomes about bad interactions).This may also include a refactoring in the zend_module_entry and the
zend_extension structs. Fe, zend_extension hooks about the op_array
could be reworked , I find the op_array_dtor_handler hook misplaced in
the chain.
zend_module_entry could also benefit from refactoring to have a better
knowing of other extensions, and a true dependency manager.That sounds like a lot of work.
+1 if somebody willing to champion that effort, but I wouldn't
delay/discard
this small improvement on the vague promise that maybe this will be
solved
as part of a bigger rfc.
just my 2 cents ofc.Yep, but the problem in adding a new hook is that today its for
feature A, tomorrow it will be for feature B, etc...
There is a risk of lack of consistency between all the ideas, that's
why I myself did not propose any single idea in this way, but prefer
merging them and propose something more consistent.
We could benefit from a new major release to have a more global
hooking strategy.
Also, as this changes the ABI by publishing a new ZEND_API, we should
consider adding this in a major and not in a stable release (even
thought that doesnt break the ABI).I agree some ideas may represent more work than others (like a
dependency management system for extensions), however, big part of the
ideas is just about "what hook to move", "where to", "why" and "what
hook to add" (and why).Also, having too many hooks can lead to many problems like extensions
incompatibility, something barely taken care of in our module API, but
which should as well be redesigned as it doesn't really work that
much.Julien.P
Those are all solid ideas and I wouldn't go against them if proposed, I'm
just a bit afraid that we end up with
http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas on
the ground of not being perfect or part of a bigger scheme while we don't
have the resources to actually make those bigger schemes a reallity.
Let see what the others think though.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:Good morning,
This is just a very small change, I propose this RFC for discussion
to
turn
the C function "gc_collect_cycles" into a pointer.https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers
fail
to capture the dynamics of GC and we need better hooks to make this
possible.There are many other things that could be turned into function
pointers to allow extensions to hook.
Our hook strategy should be reviewed entirely.Not only GC. If you look at streams, many of them are not
overwritable, and some are, but they are missing from the headers file
so you may not overwrite them.I suggest we design a wider RFC for PHP7 about what we would be able
to hook, and what not (and what is the impact, because the more you
hook , the more complex it becomes about bad interactions).This may also include a refactoring in the zend_module_entry and the
zend_extension structs. Fe, zend_extension hooks about the op_array
could be reworked , I find the op_array_dtor_handler hook misplaced in
the chain.
zend_module_entry could also benefit from refactoring to have a better
knowing of other extensions, and a true dependency manager.That sounds like a lot of work.
+1 if somebody willing to champion that effort, but I wouldn't
delay/discard
this small improvement on the vague promise that maybe this will be
solved
as part of a bigger rfc.
just my 2 cents ofc.Yep, but the problem in adding a new hook is that today its for
feature A, tomorrow it will be for feature B, etc...
There is a risk of lack of consistency between all the ideas, that's
why I myself did not propose any single idea in this way, but prefer
merging them and propose something more consistent.
We could benefit from a new major release to have a more global
hooking strategy.
Also, as this changes the ABI by publishing a new ZEND_API, we should
consider adding this in a major and not in a stable release (even
thought that doesnt break the ABI).I agree some ideas may represent more work than others (like a
dependency management system for extensions), however, big part of the
ideas is just about "what hook to move", "where to", "why" and "what
hook to add" (and why).Also, having too many hooks can lead to many problems like extensions
incompatibility, something barely taken care of in our module API, but
which should as well be redesigned as it doesn't really work that
much.Julien.P
Those are all solid ideas and I wouldn't go against them if proposed, I'm
just a bit afraid that we end up with
http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas
on the ground of not being perfect or part of a bigger scheme while we
don't have the resources to actually make those bigger schemes a reallity.
Let see what the others think though.
I agree, this change makes sense this way and is compatible to the way
hooks work right now. This change can be part of the grand refactoring
later on.
Refactoring the whole extension API is a bit time critical anyways, if we
won't find a champion for this in the next days/weeks then it won't happen
for 7.0 and then by definition (BC breaks) not for any version in 7.*
branch.
Expanding the scope of this too much will end up as failure.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I agree, this change makes sense this way and is compatible to the way
hooks work right now. This change can be part of the grand refactoring
later on.
7.0 is indeed the best time to do it.
Refactoring the whole extension API is a bit time critical anyways, if we
won't find a champion for this in the next days/weeks then it won't happen
for 7.0 and then by definition (BC breaks) not for any version in 7.*
branch.
This is not correct. The BC break clause applies only for userland.
While we try to avoid big APIs change between x.y and x.y+1, we do
allow them.
However I worry much more about what we do (not) for userland and some
bigger changes internally, those that will be very hard to sell for
7.x.
Expanding the scope of this too much will end up as failure.
--
Pierre
@pierrejoye | http://www.libgd.org
On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei <kontakt@beberlei.de
wrote:
Good morning,
This is just a very small change, I propose this RFC for discussion
to
turn
the C function "gc_collect_cycles" into a pointer.https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers
fail
to capture the dynamics of GC and we need better hooks to make this
possible.There are many other things that could be turned into function
pointers to allow extensions to hook.
Our hook strategy should be reviewed entirely.Not only GC. If you look at streams, many of them are not
overwritable, and some are, but they are missing from the headers file
so you may not overwrite them.I suggest we design a wider RFC for PHP7 about what we would be able
to hook, and what not (and what is the impact, because the more you
hook , the more complex it becomes about bad interactions).This may also include a refactoring in the zend_module_entry and the
zend_extension structs. Fe, zend_extension hooks about the op_array
could be reworked , I find the op_array_dtor_handler hook misplaced in
the chain.
zend_module_entry could also benefit from refactoring to have a better
knowing of other extensions, and a true dependency manager.That sounds like a lot of work.
+1 if somebody willing to champion that effort, but I wouldn't
delay/discard
this small improvement on the vague promise that maybe this will be
solved
as part of a bigger rfc.
just my 2 cents ofc.Yep, but the problem in adding a new hook is that today its for
feature A, tomorrow it will be for feature B, etc...
There is a risk of lack of consistency between all the ideas, that's
why I myself did not propose any single idea in this way, but prefer
merging them and propose something more consistent.
We could benefit from a new major release to have a more global
hooking strategy.
Also, as this changes the ABI by publishing a new ZEND_API, we should
consider adding this in a major and not in a stable release (even
thought that doesnt break the ABI).I agree some ideas may represent more work than others (like a
dependency management system for extensions), however, big part of the
ideas is just about "what hook to move", "where to", "why" and "what
hook to add" (and why).Also, having too many hooks can lead to many problems like extensions
incompatibility, something barely taken care of in our module API, but
which should as well be redesigned as it doesn't really work that
much.Julien.P
Those are all solid ideas and I wouldn't go against them if proposed, I'm
just a bit afraid that we end up with
http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas
on
the ground of not being perfect or part of a bigger scheme while we don't
have the resources to actually make those bigger schemes a reallity.
Let see what the others think though.
+1
I updated the RFC to include a paragraph on this. The change should be
included as-is and then be part of a potential refactoring, should one
happen.
On Thu, Dec 4, 2014 at 9:30 AM, Benjamin Eberlei kontakt@beberlei.de
wrote:Good morning,
This is just a very small change, I propose this RFC for discussion
to
turn
the C function "gc_collect_cycles" into a pointer.https://wiki.php.net/rfc/gc_fn_pointer
Composer's garbage collection optimization showed that PHP Profilers
fail
to capture the dynamics of GC and we need better hooks to make this
possible.There are many other things that could be turned into function
pointers to allow extensions to hook.
Our hook strategy should be reviewed entirely.Not only GC. If you look at streams, many of them are not
overwritable, and some are, but they are missing from the headers file
so you may not overwrite them.I suggest we design a wider RFC for PHP7 about what we would be able
to hook, and what not (and what is the impact, because the more you
hook , the more complex it becomes about bad interactions).This may also include a refactoring in the zend_module_entry and the
zend_extension structs. Fe, zend_extension hooks about the op_array
could be reworked , I find the op_array_dtor_handler hook misplaced in
the chain.
zend_module_entry could also benefit from refactoring to have a better
knowing of other extensions, and a true dependency manager.That sounds like a lot of work.
+1 if somebody willing to champion that effort, but I wouldn't
delay/discard
this small improvement on the vague promise that maybe this will be
solved
as part of a bigger rfc.
just my 2 cents ofc.Yep, but the problem in adding a new hook is that today its for
feature A, tomorrow it will be for feature B, etc...
There is a risk of lack of consistency between all the ideas, that's
why I myself did not propose any single idea in this way, but prefer
merging them and propose something more consistent.
We could benefit from a new major release to have a more global
hooking strategy.
Also, as this changes the ABI by publishing a new ZEND_API, we should
consider adding this in a major and not in a stable release (even
thought that doesnt break the ABI).I agree some ideas may represent more work than others (like a
dependency management system for extensions), however, big part of the
ideas is just about "what hook to move", "where to", "why" and "what
hook to add" (and why).Also, having too many hooks can lead to many problems like extensions
incompatibility, something barely taken care of in our module API, but
which should as well be redesigned as it doesn't really work that
much.Julien.P
Those are all solid ideas and I wouldn't go against them if proposed, I'm
just a bit afraid that we end up with
http://en.wikipedia.org/wiki/Nirvana_fallacy where we reject small ideas
on the ground of not being perfect or part of a bigger scheme while we
don't have the resources to actually make those bigger schemes a reallity.
Let see what the others think though.--
Ferenc Kovács
@Tyr43l - http://tyrael.hu