On 18/01/11 22:17, Stas Malyshev wrote: >> 1) any hints or clues from people familiar with the Zend subsystems - >> such as memory management, and the various stacks, to provide hints as >> to how to set them up "correctly" > > Zend Engine keeps all state (including memory manager state, etc.) > separate in each thread, which means once you've created a new thread > it has to run initializations for the data structures. It should > happen automatically when you build the engine in threaded mode > (--enable-maintainer-zts).
Yes, I expected the two functions - tsrm_new_interpreter() and init_executor() to do that, as it is the function called in php_request_startup() in main/main.c It seems to do a lot of the work, and as far as I could tell there is no TSRM function to reap an individual thread etc. There is also zend_startup() - which seems to do a bit more. If anyone knowledgeable would care to give or point to an overview, that would be very useful. > You can not share any data between the engine threads - unless you > communicate it through some channel external to the engine - and even > in this case you should use a copy, never the original pointer. Sure, I'm expecting to have to pass in all data as deep copies as well as the return value from the function. This is useful for array_map-like functions. The parallel_for API, while it worked in the context of HipHop, is unlikely to work with Zend; there doesn't seem to be an interpreter under the sun which has successfully pulled off threading with shared data. Another possible application would be a parallel_include() type call, which would call a given PHP file for each member of an array (or a PDO result set), buffering the output from each, and inserting into the output stream in sequence once each fragment is done (hopefully interacting well with normal output buffering, if you didn't want the results sent yet). This would allow a large number of results to be rendered in parallel on multicore systems. > This also means you can not use PHP functions, classes, etc. from one > thread in another one. I hope it will be possible to share already compiled code between threads; this may mean disabling "eval" inside the thread or otherwise hobbling the compiler to avoid separate threads trying to modify the optree at once. If a shared optree cannot be achieved, then I guess it would have to go back to the APC, but it would be good to avoid overheads where possible to keep the thread startup cost low. Even extremely restricted parallelism can help speed up some types of work, so limitations I am happy to accept. > I'm not sure what you tried to do in your code, so hard to say what > exactly went wrong there. > Another caveat: while Zend Engine makes a lot of effort to keep the > state localized and thus be thread-safe, not all libraries PHP is > using do so, so running multithreaded PHP with these libraries may > cause various trouble. Yes, currently I am not looking at calling individual module startup functions to avoid this problem (and save time on thread startup). It seems that there is a facility for limiting the available functions visible to the created executor, too, which may make this easy to make "safe". Thanks for your feedback, Sam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
