Hi,
Here is a new RFC: https://wiki.php.net/rfc/sync
Thoughts appreciated.
Cheers,
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
The title is wrong.
On Tue, Sep 30, 2014 at 11:06 AM, guilhermeblanco@gmail.com
guilhermeblanco@gmail.com wrote:
Hi,
Here is a new RFC: https://wiki.php.net/rfc/sync
Thoughts appreciated.
Cheers,
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 30/09/2014 05:06, guilhermeblanco@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
Le 30/09/2014 05:06, guilhermeblanco@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
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:
-
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. -
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. -
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 functionsposix_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.) -
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.
On 30 September 2014 04:06, guilhermeblanco@gmail.com
guilhermeblanco@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.
On 30 September 2014 04:06, guilhermeblanco@gmail.com
guilhermeblanco@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
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
Hi,
Here is a new RFC: https://wiki.php.net/rfc/sync
Thoughts appreciated.
Cheers,
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
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.
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, "guilhermeblanco@gmail.com" <
guilhermeblanco@gmail.com> wrote:Hi,
Here is a new RFC: https://wiki.php.net/rfc/sync
Thoughts appreciated.
Cheers,
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
--
Guilherme Blanco
MSN: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
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/
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.
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: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada
On Tue, Sep 30, 2014 at 10:18 PM, guilhermeblanco@gmail.com <
guilhermeblanco@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
On Tue, Sep 30, 2014 at 10:18 PM, guilhermeblanco@gmail.com <
guilhermeblanco@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
.
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
On Wed, Oct 1, 2014 at 3:08 PM, Johannes Schlüter
johannes@schlueters.de 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
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 3:08 PM, Johannes Schlüter
johannes@schlueters.de 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 easillyAnd 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: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada