> Seriously though, if at this point, all the 'base code' of PHP is > certified, could it be possible to start a checklist of which modules have > been certified and which haven't?
The question is how one would certify an extension? You can't just look at the code for 3 minutes and say, yup, this is threadsafe. I mean, you can probably do that on the PHP-side of things, but what about the real code in the 3rd-party library? And even if the library claims to be threadsafe, is it really? And are there any caveats? This is going to take some time. For example, a very popular extension is the PostgreSQL extension. libpq is theoretically threadsafe as of PostgreSQL 7.0 and higher. But you have to be careful to not share a connection object across threads which shouldn't be an issue unless we screw up when adding the planned threaded connection pooling mechanism. However, you may have a PostgreSQL PHP app that ends up calling the system crypt() function and on some platforms crypt() is not threadsafe. So even with a mainstream extension like this chances are we are going to see instability on certain platforms and it may be very difficult to track down the exact problem as such concurrency issues tend to be a pain in the ass to nail down. When we start looking at less mainstream extensions or even extensions that rely on closed-source 3rd-party libraries I have no idea where to begin certifying these things short of asking someone like you with a big busy site to run it for a while and let us know if it breaks everything or not. And even if you do this and report back that it works great, you may not have tested all paths and options so the next guy who comes along and reads this list of "certified" extensions might get burned. -Rasmus -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
