Hi Stefan, Opcode caches don't usually copy the op_array.opcodes from shared memory to process memory, so modification of opcodes may affect other processes which execute the same op_array.
As you set the extended_value in shared memory to point into process memory the other process will read it and look into it's own memory, and of course it won't find proper switch-table there. It makes sense to do this optimization before storing op_array in shared memory (in PHP compiler itself or optimizer). Thanks. Dmitry. Stefan Esser wrote: > Hello Dmitry, > > while I also believe that the extension should not be included in the > core at the moment I strongly believe that it will be compatible with > every well behaving opcode cache. > > Because it modifies op_array during execution... > a) the opcode cache is not affected at all because it always provides a > copy of the cached op_array to execute() > > or b) the modification will be performed on the cached opcodes in memory > which means the opcode cache either stores (and therefore shares) the > manipulated opcodes (with other processes) or not. Either way any > process loading the opcodes that were manipulated by another process > should recognise the loaded op_array as not yet optimized. Therefore the > optimization will be repeated in the other process again => No problem > at all. > > Therefore only on edge cases, where 2 processes share the same memory > addresses for the switchtables a malfunction due to an opcode cache can > happen. (I will improve that by a canary value that is different for > each process and that I will store in the extented_value of the JMPZ > opcode that is following the CASE) > > Attention: switchtable is not threadsafe at the moment > > > Stefan Esser -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
