Re: [PHP-DEV] [RFC] Move pecl_sync to core
On Tue, Sep 30, 2014 at 10:18 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: What does that even mean? It means that any new functionality that gets into core could be considered young. Like when PHAR got introduced, it was a young extension. Same for PDO, same for FileInfo... What I'm trying to highlight is that being a recently coded extension or not, it's not a good argument to say join/no join. phar is a really bad example, the maintainers left right after it was accepted into the core making it a really bad technical burden, as it tightly integrated into the streams handling and stuff, making it a liability. from the average user POV I think it would be a bit weird why do we add a relatively new package which is at the bottom of the download stats ( http://pecl.php.net/package-stats.php) while not bundling stuff like memcache or mongo which are both mature and used/required by much more people/project. 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On Wed, 2014-10-01 at 14:26 +0200, Ferenc Kovacs wrote: On Tue, Sep 30, 2014 at 10:18 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: What does that even mean? It means that any new functionality that gets into core could be considered young. Like when PHAR got introduced, it was a young extension. Same for PDO, same for FileInfo... What I'm trying to highlight is that being a recently coded extension or not, it's not a good argument to say join/no join. phar is a really bad example, the maintainers left right after it was accepted into the core making it a really bad technical burden, as it tightly integrated into the streams handling and stuff, making it a liability. from the average user POV I think it would be a bit weird why do we add a relatively new package which is at the bottom of the download stats ( http://pecl.php.net/package-stats.php) while not bundling stuff like memcache or mongo which are both mature and used/required by much more people/project. 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. Afternoon, I think you got your answer anyway, so this message might fall on deaf ears. The assertion that there is no way to use mutex in a cross platform way in PHP is actually wrong: http://php.net/mutex The number of people that should be using mutex directly in PHP is about 4. PHP programmers are ill prepared for using such things, making some code exist, doesn't prepare anyone. With a quick glance, there is a number of mistakes in the code. There is an incorrect assumption that what this is doing is safe, it is not. You cannot share a mutex across process boundaries without setting attributes on creation, this includes forked child processes; given PHP's normal mode of execution does involve forking and multi-processing, the ideas in this extension are very close to useless. If this extension were well written and had all bases covered it still wouldn't make sense to include it, handing over synchronization to userland simply will not work. So, as you might have guessed, a -1, and your barking mad from me. Cheers Joe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
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. johannes signature.asc Description: This is a digitally signed message part
Re: [PHP-DEV] [RFC] Move pecl_sync to core
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
Re: [PHP-DEV] [RFC] Move pecl_sync to core
Hi, Ferenc nailed why this RFC could be considered invalid. Maintenance burden and separate releases would be bad if tied to php-src. I'll update its status to declined. Joe, as I said in the RFC, Mutex could only be supported through pthreads PECL. So your answer was still not 100% accurate from my POV. Julien, you know I don't feel offended with no-go feedbacks. All I want is a reasonable argumentation over a topic and general consensus. Cheers, On Wed, Oct 1, 2014 at 9:46 AM, Julien Pauli jpa...@php.net wrote: 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 -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On 9/29/2014 8:06 PM, guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. Cheers, As the original author of this extension, I only have a few caveats to point out: 1) It has a dependency on POSIX semaphores on non-Windows platforms. From what I understand, not all platforms have support for POSIX semaphores. I feel that if this is going to be moved to core that someone with a deeper familiarity of POSIX support across OSes take a look at what platforms won't be supported and whether or not anyone actually cares about the unsupported environments. Every modern distro I've tried has support. 2) Another consideration is the use of the code in common shared hosting environments. If two objects share the same name but are used differently in two different applications on the same machine, it will result in undefined behavior. The object won't crash but it won't necessarily behave the way it is intended to behave. This is true of any synchronization object, but is something to be aware of as a possible issue since the code does expose OS level synchronization objects to web applications. Much of this issue is minimized by making the different types of objects (Mutex, Semaphore, etc.) have unique prefixes but it doesn't mean there can't/won't be any conflicts. 3) Creating a POSIX named object as 'root' and then attempting to open it as another user fails with an obscure permission denied error. This can happen if the object is initially created by a cron job that's run as root and then a web application attempts to open the same object later on. The userland functions posix_setuid()/posix_seteuid() and/or posix_setgid() can be used to counter the effect. (Whether or not PHP based cron jobs should run as the root user is a different discussion.) 4) The naming scheme of the various named objects should be examined to make sure they conform to any existing naming conventions. For example, the name hello becomes /Sync_Mutex_hello_0 in a POSIX named mutex object while the name is left as hello in a Windows named mutex object. Just a few thoughts. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On 30 September 2014 04:06, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. What are the actual benefits of this being included in core? The RFC doesn't really list any. Also, there was a discussion in June (started by Julien) about refactoring PHPs IO layer, where many people expressed a wish to have something libuv based in core, this comes with cross-platform semaphors and mutexes as well as a TON of other awesome goodies. If anything, this is what I would prefer in core. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On Tue, Sep 30, 2014 at 8:58 AM, Leigh lei...@gmail.com wrote: On 30 September 2014 04:06, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. What are the actual benefits of this being included in core? The RFC doesn't really list any. Also, there was a discussion in June (started by Julien) about refactoring PHPs IO layer, where many people expressed a wish to have something libuv based in core, this comes with cross-platform semaphors and mutexes as well as a TON of other awesome goodies. If anything, this is what I would prefer in core. Why would you use PHP for such low level concepts ? I don't think this is useful, better write C for the target platform I think. And this extension is very young and may be very buggy as it plays with lots of crossplatform-hell concepts. Why would we support it in Core ? Julien.P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On Tue, 30 Sep 2014, Remi Collet wrote: Le 30/09/2014 05:06, guilhermebla...@gmail.com a écrit : Here is a new RFC: https://wiki.php.net/rfc/sync Isn't this extension a bit young to join php core ? I'd say both that, and that the RFC is *very* minimal. THere is no rationale why this should be part of the code for example. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
This needs a Why section. Why is this good for PHP? Why will a significant percentage of users be interested in this? Why is it necessary? This feel pretty niche to me. -Sara On Sep 30, 2014, at 4:06, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. Cheers, -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
Fix the title? :) Is it for sync or pecl_http? Someone already fixed that. Isn't this extension a bit young to join php core ? I agree. However, there's no equivalent existing support in PHP atm. Also, any new functionality introduced to PHP would always be new, young and caring maturity. What are the actual benefits of this being included in core? The RFC doesn't really list any. I updated the RFC to include some rationale around it. Also, there was a discussion in June (started by Julien) about refactoring PHPs IO layer, where many people expressed a wish to have something libuv based in core, this comes with cross-platform semaphors and mutexes as well as a TON of other awesome goodies. If anything, this is what I would prefer in core. I would love that, because it would make this RFC obsolete IF the low level API also gets exposed to userland. But if I/O gets refactored we have 2 alternatives: - Locking is built-in concurrency intensive places, such as file creation, writing, cache inclusion, etc. - Low level API gets exposed to consumers, then any extension or userland code could benefit Why would you use PHP for such low level concepts ? I think I was able to answer that through the rationale section exposing an example on RFC. Please reply back if not. Why would we support it in Core? Why is this good for PHP? PHP doesn't offer an easy cross-platform way to implement locking. All you can do is through flock emulating Mutexes and Semaphores, but even this is not cross-platform; for example, Windows does not support blocking until it acquires the lock. Why will a significant percentage of users be interested in this? Why is it necessary? Not a significant percentage would use it at userland level, I agree. However, low level libraries could benefit that would later benefit many other projects and people. I, for example, would consider to add locking support inside of Doctrine\Cache, which would benefit Zend, Symfony, Drupal, CMSs and many other projects that rely on this low level abstraction API. But currently, I'm unable to do it since there's no PHP support and also because we avoid enforcing the necessity of PECL extensions to get code up and running. PHP is not a toy language anymore and more robust functionality is severely needed to the language move forward. I consider Locking is one of the missing pieces to the language, but the world is not made of Guilherme Blanco's... =P PS: I'll answer Thomas' email later. On Tue, Sep 30, 2014 at 1:27 PM, Sara Golemon p...@golemon.com wrote: This needs a Why section. Why is this good for PHP? Why will a significant percentage of users be interested in this? Why is it necessary? This feel pretty niche to me. -Sara On Sep 30, 2014, at 4:06, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. Cheers, -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] [RFC] Move pecl_sync to core
On 30 Sep 2014, at 20:56, guilhermebla...@gmail.com wrote: Isn't this extension a bit young to join php core ? I agree. However, there's no equivalent existing support in PHP atm. That, in itself, is not necessarily a justification. Unless an awful lot of PHP users need this, it shouldn’t be in core. Also, any new functionality introduced to PHP would always be new, young and caring maturity. What does that even mean? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
What does that even mean? It means that any new functionality that gets into core could be considered young. Like when PHAR got introduced, it was a young extension. Same for PDO, same for FileInfo... What I'm trying to highlight is that being a recently coded extension or not, it's not a good argument to say join/no join. On Tue, Sep 30, 2014 at 4:05 PM, Andrea Faulds a...@ajf.me wrote: On 30 Sep 2014, at 20:56, guilhermebla...@gmail.com wrote: Isn't this extension a bit young to join php core ? I agree. However, there's no equivalent existing support in PHP atm. That, in itself, is not necessarily a justification. Unless an awful lot of PHP users need this, it shouldn’t be in core. Also, any new functionality introduced to PHP would always be new, young and caring maturity. What does that even mean? -- Andrea Faulds http://ajf.me/ -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada
Re: [PHP-DEV] [RFC] Move pecl_sync to core
The title is wrong. On Tue, Sep 30, 2014 at 11:06 AM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Thoughts appreciated. Cheers, -- Guilherme Blanco MSN: guilhermebla...@hotmail.com GTalk: guilhermeblanco Toronto - ON/Canada -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Move pecl_sync to core
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 30/09/2014 05:06, guilhermebla...@gmail.com a écrit : Hi, Here is a new RFC: https://wiki.php.net/rfc/sync Isn't this extension a bit young to join php core ? Remi. Thoughts appreciated. Cheers, -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQqQhsACgkQYUppBSnxahjVcACfatuWm6PyLRnAJ/nSV3Y5f6Jz 2k0AnjpvL3TjiL95RnoOu/uMPzlmnnAF =Sh/V -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
