On 09/08/2012 12:26 PM, Lars Strojny wrote: > That’s indeed a different topic but it would ease a lot of pain to have a > fully compatible APC from day one.
The first step to that is to make sure all new language features include the necessary changes to APC. And despite what Pierre thinks, it hasn't been the non-opcode features that have been holding us back. It has been traits and the interned string changes in the engine for the most part. We could drop some of the ini switches and just hardcode some things, but there are really just two main things in APC. The opcode cache and the user cache. The user cache is used quite a bit out there, but I suppose we could still have a pecl/apc that adds that back. But it all comes down to someone actually doing the work. We don't have a lot of people capable of doing this. I would say getting opcode caching right is even more complicated than the engine code itself. In the engine we don't have to worry about concurrent access to the same chunk of memory - essentially threaded programming and it gets really nasty. Gopal even patched Valgrind to help debug and catch APC issues. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php