[RFC] Move pecl_sync to core

10 years ago by Gasol Wu — view source

unread

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

10 years ago by Remi Collet — view source

unread

-----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

10 years ago by Derick Rethans — view source

unread

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

10 years ago by Thomas Hruska — view source

unread

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 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.)
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/

10 years ago by Leigh — view source

unread

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.

10 years ago by Julien Pauli — view source

unread

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

10 years ago by Sara Golemon — view source

unread

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

10 years ago by guilhermeblanco@gmail.com — view source

unread

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

10 years ago by Andrea Faulds — view source

unread

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/

10 years ago by guilhermeblanco@gmail.com — view source

unread

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

10 years ago by Ferenc Kovacs — view source

unread

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

10 years ago by Joe Watkins — view source

unread

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

10 years ago by johannes@schlueters.de — view source

unread

.
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

10 years ago by Julien Pauli — view source

unread

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

10 years ago by guilhermeblanco@gmail.com — view source

unread

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 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: guilhermeblanco@hotmail.com
GTalk: guilhermeblanco
Toronto - ON/Canada