Re: php4-apache2 [was: Re: Top 5 things (php4-apache2)]
On Thu, Jan 22, 2004 at 09:46:47AM -0600, Steve Langasek wrote:
[PHP4 and threaded apache2]
> They really ought to take a page from the freeradius book, and include
> "is threadsafe, y/n" as a flag on their extension definitions. By
> including it in the extension API, they can ensure that the performance
> penalties only affect those users who actually *use* non-threadsafe
> libraries, instead of having the whole thing come crashing down due to
> the use of non-threadsafe libs.
>
> So if you talk to him again soon, maybe you can suggest this to him.
> I've been muttering this for years, but I don't think anyone pays
> attention to my mutterings. :)
That was suggested, and by the look on his face it'd been suggested before.
The problem is, who makes the decision as to whether something is
thread-safe? How can you actually be sure that something is thread safe?
Rasmus gave a couple of examples of libraries which even *claimed* to be
thread safe but which actually contained complex race conditions within
themselves, and caused occasional catastrophic and incredibly hard to debug
problems. Unfortunately I can't remember which library it was now he
mentioned, but I remember the failure was a login-related one. Might have
been a database or mail access library...
The problems get worse. An otherwise ABI-compatible change in a library
that a PHP extension depends on can change the thread-safetyness of the
extension. So it's hard to "certify" an extension thread-safe when it
depends on externally maintained libraries whose bugginess can't be
determined - more so when thread safety is not something you can apply a
simple checklist to to determine compliance.
Libraries depending on libraries exacerbates the problem. Now, you not only
have to check the thread-safety of the library you directly depend on, but
also the libraries that your dependent library uses. And what happens when
multiple libraries provide the same ABI? I'm thinking, as a particular
example, of OpenSSL and the GNUTLS OpenSSL compatibility layer. If one of
those is thread-safe and the other isn't, how can you say that your
extension which makes indirect use of OpenSSL (say, by using it to provide
IMAPS or LDAPS support) is thread safe? You can't, because you can't be
sure that everyone is going to use the thread-safe one, without gratuitously
breaking support for one of them. And you can be sure as shit that the
moment someone uses your "thread-safe" extension, and it bombs, they're
going to want your head - ignoring the skywriter you hired to write "PHP
extension foo is not thread-safe when linked with XYZ library" over the
complainant's house.
And, as a kind of coup de grace, when thread safety is violated, the
problems are not necessarily immediately and unequivocally obvious. The
problems may only show under load, so they're not easy to reproduce. The
problem may only show itself when certain versions, or combination of
versions, of libraries and extensions are used together. And the problem,
once manifested, may not be easily traceable back to the true root cause of
the problem.
I'm not trying to claim that any one of these problems is unique to a
threaded PHP4 system - a lot of the issues aren't even unique to thread
safety - but they all do exist in PHP4 as it stands, and without very
aggressive mutexing (to the point of pointlessness, as was quipped) the
safety of PHP4 is in doubt. And the feeling I get from Rasmus, after
talking to him and hearing his tutorial on PHP4 Tips and Tricks, is that
above all he wants PHP to be unexciting and reliable. And a version of PHP
that depends on the thread-safety of over 100 external libraries for it's
correct operation definitely falls into the "exciting" category.
- Matt
Reply to: