On Sat, Jan 10, 2015 at 9:12 AM, François Laupretre <franc...@tekwire.net> wrote: > De : Pierre Joye [mailto:pierre....@gmail.com] > >> Opcache is why I think we should have a list registered names. A simple hash >> exists and the cache will know what to do. > > Sorry, I am not sure I understand how the opcode cache, as it exists now, can > understand this. Do you mean that opcode cache code would need to be modified > ?
Yes and no. Yes if we want them to do not even try to update files that are statically built in extensions. And yes, if we want that (for whatever reasons I cannot think about right now). > Anyway, that's the occasion to ask this : do we consider opcache the only > supported opcode cache in the future or do we still support APC and other > alternative opcode caches. I'd like to know if we are free to improve the way > opcode cache communicates with the core, or if we must keep BC. That's PHP7, we can and have already broke BC internally. Patch now in my fork (finally got a faster connection): https://github.com/pierrejoye/php-src/compare/php:master...master Date use as example. Key are two parts: . the configure script to create the static data (could actually be used for any binary data btw) . the zend_execute_string call, which could happen anywhere where it could be done, RINIT making more sense right now As Sara pointed out , persistent opcode would be way better but as far as I remember it is something very tricky to do (due to how the address and offset are stored), maybe it changed now for 7, I did not check that part. In any case the exec_string and the binary to C scripts will be helpful there too. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
