Re: Re: Thread safe extension homologation
| From: | Manuel Lemos | Date: | Sat, 30 Sep 2006 05:42:26 +0000 |
| Subject: | Re: Re: Thread safe extension homologation | ||
| References: | 1 2 3 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-4203@lists.php.net to get a copy of this message | ||
Hello,
on 09/28/2006 05:31 PM Rasmus Lerdorf said the following:
> Also note that just because it may be threadsafe on one platform doesn't
> mean it will be threadsafe on another. Even on the same platform, the
> libc version, openssl version and just about any system-level library
> the extension requires can cause the extension not to be threadsafe. So
> you would need an amazingly complicated matrix looking something like:
Right, we need to be practical. I do not think it is important to figure
on which platforms an extension would be thread-safe, but rather answer
the question: "if I build PHP with this, that and the other extension,
would it be thread safe? If not, what extensions/libraries prevent that
to happen?"
I am not sure how complicated it would be, but maybe that answer could
be given by running configure with specific arguments. By the time
configure is done, it knows what extensions and libraries it will link with.
If the configure script could be generated also give the answer to the
questions above, then developers would know what is the problem. Maybe
that would tease developers to help validation/fixing any extensions
that were not validated or have known thread-safety problems.
> Add to that the fact that there is no real way to definitively say that
> something is threadsafe even if you limit it to a single platform with a
> defined set of libraries. There are no decent tools that will
> definitvely say whether there is a race condition hiding somewhere just
> waiting for the right combination of events to occur. The best you
> could ever do would be to go through the code and pick out uses of known
> unsafe functions like crypt() and thereby definitively state that
> something isn't threadsafe.
That would be a start. It would help us to figure what needs to be
fixed. It may be a lot of work, but I think it can be done.
The way I see it, a lot of work was already done to build TSRM. If we
could put that work to help turning unsafe into thread-safe extensions,
the whole PHP community would benefit of PHP versions that can run in
more efficient environments, instead of having to switch to whatever
languages or platforms claimed to be more efficient.
--
Regards,
Manuel Lemos
Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/
PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/