On Wed, Oct 1, 2014 at 3:08 PM, Johannes Schlüter <johan...@schlueters.de> wrote: > On Wed, 2014-10-01 at 14:26 +0200, Ferenc Kovacs wrote: >> . >> personally I think that a pecl extension needs to have stronger arguments >> to be bundled with php-src than the fact that it would probably create a >> bit more exposure for the ext. >> > > Fully agree and mind this: > > For an average user it doesn't really make a difference if we bundle it > or not - linux distributions move even bundled extensions into own > packages and package pecl ones, too. On Windows installers bundle pecl > things too. > > For the extension maintainer not being bundled has the benefit of having > its own release cycle. They are not bound to core PHP's rules and add > minor features as they like and roll bug fixes as needed, while even > fixes are simpler - they don't have to merge between as many branches. > > For core PHP having it in PECL has the benefit that a showstopper in the > extension won't stop the PHP release. If the extension takes a week more > that is fine. > > One might say that is a downside of using pecl that less people test it > and in core the extension would receive more attention but I seriously > doubt that many core developers enable all extensions (lester i.e. > rightfully complains about the lack of attention on firebird) > > Now looking at this specific thing: PHP is a shared nothing environment > for handling web requests. By having the isolation between request > containers we can easily scale PHP by adding more machines, which is > easy as we don't share state. sync does the opposite, its purpose is to > break this isolation and offering a way to make request dependent on > each other. There are cases where this is useful and it is great that we > have a module with this option but in my opinion is not what PHP core > should do. And yes, we have sysvmsg, sysvsem and sysvshm in the core > distributions, but in my opinion more due to the fact that they predate > pecl by a few years.
That's a good sum-up. Locking is the opposite of PHP model, which is based on non-locking model, fire-and-forget , scale easilly And seriously, if you need locking, mutexes etc... in PHP, then you should probably write your stuff in C or Java. The PHP engine can't fully support such concepts to provide them to userland, or at least it won't be cheap in human effort to have such a thing reach a stable state so that we can ship it into PHP. This is not a troll, or a "go away from PHP", please don't feel offended , but PHP is just not designed to do that, this is not the language you'll use when you face such problems. PHP is mature, but still has a target, don't target something its not been designed for. Julien.Pauli -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
